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PREFACE 



The information in this publication is 
organized to enable you to read selective- 
ly: for an overview of a function per- 
formed by the MVT Supervisor, or for the 
details of how that function is performed. 
The "Introduction" section describes the 
general operation of the MVT Supervisor. 
The following sections: "Interruption Han- 
dling," "Task Supervision," "Contents 
Supervision, " and so on, describe functions 
first in general terms, and then in detail. 

Your reading of this PLM will be aided 
by the reference information that appears 
in the sections at the back of the book. 
The sections consist of "Control Blocks and 
Tables," "Program Organization," and "Flow 
Charts." The tables in the "Program 
Organization" section tabulate varied 
information about each supervisor routine: 
ent3:y point name, routine name, module 
name, library name, invoking macro instruc- 
tion, etc. 

Note: The area of main storage used exclu- 
sively by system routines is called, in 
this manual, "supervisor queue area" or 
"supervisor queue space." In MVT Guide it 
is called "system queue area." 

PREREQUISITE PUBLICATIONS 

IBM Svstem/360 Operating System: 
MVT Guide , GC28-6720 

Supervisor Services and Macro Instruc- 
tions , GC28-66U6 

Data Management Macro Instructions . 
GC26-379«I 

Messages and Codes . GC28-6631 (useful 
for the formats and meanings of messages 
and codes) 



PUBLICATIONS TO WHICH THE TEXT REFERS 

IBM System/360 Principles of Operation , 
GA22-6821 (referred to in "Interruption 
Handling" ) 

IBM Svstem/360 Operating System: 

Job Control Language Reference . GC28- 
670U (referred to in "Checkpoint/ 
Restart" and "Abnormal Termination") 



Linkage Editor, Program Logic Manual . 
GY28-6610 (referred to in "Contents 
Supervision") 



Linkage Editor and Loader . GC28-6538 
(referred to in "Contents Supervision") 



MVT Job Management. Program Logic Manu- 
al . GY28-6660 (referred to in "Task 
Supervision" and "Checkpoint/Restart") 



I/O Supervisor. Program Logic Manual . 
GY28-6616 (referred to in the descrip- 
tion of the Program Fetch routine in 
"Contents Supervision," in the descrip- 
tion of the rollout/rbllin Start Transf- 
er routine in "Main Storage Supervi- 
sion," and in "Interruption Handling") 



Machine-Check Handler for the Model 65 
Program Logic Manual . GY27-7155 
(referred to in "Interruption Handling") 

Machine-Check Handler for the Model 85 
Program Logic Manual . GY27-718U 
(referred to in "Interruption Handling") 

Machine-Check Handler for the Svstem/370 
Models 135 and 145 . GY27-7237 (referred 
to in "Interruption Handling") 

Machine-Check Handler for the Svstem/370 
Models 155 and 165 . GY27-7198 (referred 
to in "Interruption Handling") 

Online Test Executive Program, Program 
Logic Manual , GY28-6651 (referred to in 
"Termination Procedures") 

Service Aids Logic. Program Logic Manu- 
al . GY28-6721 (referred to in "Interrup- 
tion Handling" and "Special Features") 

System Generation . GC28-6554 

(referred to in "Interruption Handling") 

OTHER PUBLICATIONS 

TSO Control Program . GY27-7199 
(describes the logic of the Time Sharing 
Option which is accessed by the MVT 
Supervisor) . 
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Item 



Generalized 
Trace Facility 



{- 



~+ 



Description 






New facility that monitors and records system events. 



Sections 
Affected 

1, 2, 10, 11, 12, 
13, It 



H 



Extended SVC 
Router 

System/370 
Model 195 



New routines that provide linkage to Supervisor 
Service routines. 



2, 13, 14 



-+ 



This CPU performs processing identical to the 
System/360 Model 195. 



2, 11, 13, 14 



Machine Check 
Record 

t 

IFCEREPO 

Shared DASD 



New record containing inf oirmation collected by SERO 
and SERl. 



2, 12 



I — 

Inter- Part- 
ition Post 
h 

Multiple-Line 
Write to Oper- 
ator routines 



A service aid that formats and writes SYSl.LOGREC 
records . 

The restriction on Shared DASD Support by the Model 
65 Multiprocessing System has been removed. 



The Post routine checks for Post parameters in the 
user parameter list. 



3, 13 



New routines to process multiple^ line WTOs in systems 
both with and without MCS. 



7, 12, 13, 14 



Graphic Console 

Initialization 

Module 

Console Support 
routines 

DIDOCS rou- 
tines 



New routine that initializes display console |7, 13, 14 
con f i gu r at ion . 



— ^ 



New routines to process multiple- line WTOs. 



H 



New routines that provide an interface between DIDOCS 
and MCS, and process console requests. 



7, 13, 14 






7, 12, 13, 14 



Restart 
routines 



+- 



New routines to process TCAM, SYSIN, ISAM, BDAM, and 
DOS data sets. 



8, 13, 14 



ABDUMP 
routine 



New modules to display trace data. 



h 



Abnormal Term- 
ination rou- 
tine (ABEND) 



The ABEND modules have been reorganized according to 
functional processing. 



10, 13, 14 
10, 12, 13, 14 
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Damage Assess- 
ment routine 
(DAK) 



The DAR modules have been reorganized according to 
functional processing. 



10, 12, 13, 14 



h- 



ABEND/STAE 
Interface 
routine (ASIR) 



The ASIR modules have been reorganized according to 
functional processing. 






10, 12, 13, 14 
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Diagnostic 
Aids in ABEND 
Processing 



Debugging aids. 



Appendix A 
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SECTION 1; INTRODUCTION 



The MVT supervisor is one part of the 
control program of IBM System/Seo Operating 
System; it controls the basic computing 
system and programming resources needed to 
perform several data processing tasks con- 
currently. The entire control program is 
introduced in the MVT Guide. 



executed in the performance of task A has 
been interrupted, possibly because it con- 
tained a request for a supervisor service, 
possibly because an input/output operation 
has been completed for an entirely dif- 
ferent task. 



Job steps, designated by the job manage- 
ment routines as tasks, are carried out 
under the control of the supervisor, which 
allocates needed resources on the basis of 
priorities. The supervisor assigns the 
resources to perform tasks, keeps track of 
all such assignments, and ensures that the 
resources are freed upon task completion. 
If one resource is required for the perfor- 
mance of several tasks, queuing of requests 
may be required. The supervisor thus main- 
tains control of resources that can be 
shared. This enables more efficient use of 
the central processing unit, main storage, 
system and user programs, and the interval 
timer. 

All supervisor activity begins with an 
interruption. In IBM System/360 the inter- 
ruption is a machine characteristic; it is 
the means by which the supervisor gets con- 
trol of the CPU to provide resources for 
the performance of tasks. An interruption 
may be planned (specifically requested in 
the program currently being executed by the 
CPU) or unplanned (caused by an event that 
may be either related or unrelated to the 
task currently being performed) . 

There are five types of interruptions: 

• Supervisor call (SVC) interruption: a 
request for a particular supervisor 
service. 

• Timer /external interruption: an atten- 
tion signal from the System/360 interv- 
al timer, the console interrupt key, or 
the direct control feature. 

• Input/output interruption: the signal 
that an input/output event has 
occurred. 

• Program interruption: a signal that a 
program has attempted an invalid 
action . 

• Machine-check interruption: the signal 
that a machine error has occurred. 



The interruption-handling portion of the 
supervisor (represented by the top box in 
Figure 1-1) analyzes the interruption, 
based on control information passed to it 
at the time of the interruption. Each of 
the five interruption types has associated 
with it two program status words (PSWs) 
called "old" (OPSW) and "new" (NPSW) . The 



Machine Loads 
New PSW 



Program Being Executed 
for Task A 



Any 
Inferruption 



Program Being Executed ^ 

for Task B \ 



\ 



Load Old PSW 



Interruption Handling 



o Analyze the interruption 

o Determine control program action 
required 

o Route control to appropriate part oF 
control program 



Performing the Service 



o Establish, alter, or end a task 

o Establish linkage to a program in main 
storage or on auxiliary storage 

o Allocate or Free main storage 

o Supervise use oF interval timer 

o Handle console communications 

o Supervise input/output operations 

o Provide program monitoring service 

(TESTRAN) 
o Provide system environment recording 

and/or attempted recovery 



Note: {Some of these services may require 
another service, and may thus cause 
the supervisor cycle to be restarted 
with another Interruption) 



Branch 



Dispatching 



o Service requests for asynchronous exits 

o Determine which task that con be 
performed has highest priority 

o Route control to a routine that performs 
the task 



Note: The dispatcher may determine that the 
interrupted task should be resumed, or 
that a different task should be 
performed . 



Overall operation of the supervisor is Figure 1-1, 

shown in Figure 1-1. The program being 



Overall Flow of the 
Supervisor 
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OPSW contains the information needed by the 
supervisor to analyze the interruption. 
The NPSW contains the address of the appro- 
priate interruption handling routine. 



When an interruption occurs, the CPU 
stores the contents of the current PSW in 
the OPSW for that type of interruption, and 
loads the NPSW. By loading the NPSW, the 
CPU places itself in supervisor state and 
passes control to the interruption handling 
portion of the supervisor. The supervisor 
then passes control to those parts of the 
control program that perform the services 
required as a result of the interruption. 

The supervisor itself performs many of 
the services that are requested through an 
interruption (these services are repre- 
sented by the middle box in Figure 1-1) . 
Services that the supervisor provides may 
be grouped into these general categories: 

• Task supervision . The supervisor 
creates tasks at the request of the job 
management routines or in response to a 
request to attach a subtask to an 
already existing task. The supervisor 
determines in what order tasks are to 
be performed. 

• Contents supervision . The supervisor 
keeps records of all programs in main 
storage, and assigns these programs to 
perform tasks. The Program Fetch rou- 
tine brings requested programs into 
main storage from secondary storage. 

• Main storage supervision . The supervi- 
sor assigns main storage needed to per- 
form job steps and tasks within job 
steps. 

• Timer supervision . The supervisor con- 
trols the use of the System/360 interv- 
al timer. 

• Console communications and the system 
log and hard copy log . The supervisor 
provides the means for the operator to 
directly communicate with the system, 
and for a program to write a message to 
the operator or programmer. It also 
supports the system log, which records 
statistical information about system 
usage. When using the Multiple Console 
Support (MCS) option, a hard copy log 
can be specified to record operator 
commands, system messages and commands, 
and application program messages. The 
hard copy log can be either a console, 
or the system log. 

• Recording and using checkpoints . On 
request, the supervisor writes records 
of a task's main storage region and the 
necessary task control information so 



that the task may be restarted from 
that point at a later time. 

• Exiting procedures . The supervisor 
provides routines that prepare for the 
return of control from a completed 
program. 

• Task termination . The supervisor pro- 
vides for normal and abnormal termina- 
tion of tasks. 

• Recovery management . The optional ser- 
vice routines SERO and SERl provide for 
the recording of information related to 
a machine malfunction. The Machine- 
Check Handler (MCH) , optional program- 
ming support for Model 65 (MCH/65) and 
standard programming support for Model 
65 Multiprocessor, the Model 85 (MCH/ 
85) , and the System/370 Models ia5 
(MCH/145) , 155 (MCH/155) , and 165 (MCH/ 
165), performs the following functions: 
(1) records environmental data, and (2) 
attempts to analyze the malfunction and 
restore the system to normal operation. 

The Channel-Check Handler (CCH) pro- 
vides programming support for models 
using the 2860/2870/2880 and System/370 
Models 145 or 155 integrated channels. 
CCH aids the device- dependent error 
recovery procedures in recovering from 
channel errors by providing them with 
channel logout information. CCH also 
builds inboard record entries to be 
written on SYSl.LOGREC. 

Alternate Path Retry (APR) allows an 
I/O operation that has developed an 
error on one channel to be retried on 
another channel (if another channel is 
assigned to the device performing the 
I/O operation) . APE also provides the 
capability to VARY a path to a device 
online or offline. The selective retry 
function of APR is optional for MVT and 
standard for M65MP. The VARY PATH 
function of APR is standard for both 
MVT and M65MP. 

Dynamic Device Reconfiguration (DDR) , 
optional programming support that is 
not model-dependent but is automatical- 
ly included for M65MP, allows a 
demountable volume to be moved from one 
device to another, and repositioned if 
necessary, without abnormally terminat- 
ing the affected job or reperforming 
IPL. A request to move a volume may be 
initiated by either the operator or the 
system, for SYSRES or non-SYSRES 
devices . 

After a control program service has been 
performed, the supervisor determines what 
task is to be performed next. The supervi- 
sor Dispatcher routine (represented by the 



bottom block in Figure 1-1) returns control 
to a processing program (or possibly to a 
supervisor routine) . As seen in Figure 
1-1, the program to which control passes 
need not be the one that was interrupted. 
The Dispatcher may determine that as a 
result of the interruption, task B, which 
has a higher priority than task A, should 
be performed next. 



TASK SUPERVISION 

Each task to be performed by the system 
is represented by a task control block 
(TCB) . The TCB contains control and status 
information related to the task, and point- 
ers to system resources assigned to perform 
the task. 

When the operating system is generated, 
certain key TCBs are built into the system. 
These TCBs represent: the master scheduler 
task of job management, the system error 
task, the rollout/rollin task,^ the com- 
munications task, and one transient area 
fetch task for each transient area. All 
other task control blocks are constructed 
by the supervisor Attach routine, at the 
request of either the control program or a 
user program. The Master Scheduler can 
attach up to fifteen Initiator/Terminator 
tasks, one for each storage protection key 
available- Initiator/Terminator routines 



attach job step tasks and subtasks. An 
entire tree structure of related tasks may 
thus be formed. 

All the TCBs in the system are chained 
together, according to dispatching priori- 
ty, to form the TCB queue. The transient 
area fetch TCBs are at the top of the 
queue, followed in order by the system 
error TCB, the rollout/rollin TCB,^ the 
communications TCB, and the master sched- 
uler TCB. The dispatching priorities of 
other tasks are assigned by the supervisor 
according to the parameters given in ATTACH 
macro instructions. When several TCBs with 
the same priority appear in the TCB queue, 
they are ordered first-in, first-out. 

Figure 1-2 shows the flow of control 
that results from the issuance of the 
ATTACH macro instruction. This flow is 
typical of the processing that might follow 
a supervisor macro instruction. 

The Attach routine, like other SVC rou- 
tines, is entered as a result of an SVC 
interruption. The SVC interruption han- 
dling routines analyze the interruption, 
determine what service is required, and 
then branch to the Attach routine. The 



^This is included if the rollout feature is 
selected at system generation. 



Program Performing 
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SVC Interruption 
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Figure 1-2. Flow of control After the ATTACH Macro Instruction Is Issued 
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Attach routine obtains main storage space 
for a TCB by issuing the GETMAIN macro 
instruction. This causes another SVC 
interruption, called a nested interruption 
because it is an interruption to the pro- 
cessing of an interruption. The nested 
interruption is handled by the supervisor 
in exactly the same way as the original 
interruption for the ATTACH macro instruc- 
tion, except that this time the interrup- 
tion handler branches to the GETMAIN rou- 
tine. When the required storage has been 
allocated, the Attach routine regains con- 
trol. It initializes certain fields in the 
TCB and places it on the TCB queue. 

After the Attach routine has initialized 
the control block that represents the new 
task, it branches to the Dispatcher. The 
Dispatcher examines the TCB queue to find 
the highest-priority task that is ready to 
be performed. This task may or may not be 
the one that was being performed at the 
time of the original SVC interruption. For 
example, if task B has been attached as a 
subtask of task A, and if B has a higher 
dispatching priority than A, then task B 
will be perfoinned before task A is resumed. 

The supervisor controls the order in 
which tasks are performed. This control is 
accomplished by the Dispatcher, working 
through the TCB queue. The highest- 
priority task represented on the TCB queue 
may not be the one to be performed; it may 
be waiting for some event (through the WAIT 
macro instruction, for example) or for a 
resource that has been serialized (through 
the ENQ macro instruction) . The TCB queue 
serves as a record of the status of every 
task in the system. 

When the time-slicing feature is 
included in the system, the dispatcher will 
contain special code for time-slicing 
implementation. The dispatcher controls 
time slicing through the time-slice control 
element (TSCE) ; there is one TSCE, 
assembled at system generation, for each 
time-slice group. 



CONTENTS SUPERVISION 

Contents Supervision is accomplished 
through a structure of queues that are very 
closely related to the TCB queue. These 
are the request block queues. 

Request blocks (RBs) represent levels of 
control within a task. Contents Supervi- 
sion routines construct an RB for the first 
level of control in the performance of a 
new task; this RB and RBs for subsequent 
levels are chained on the TCB's RB queue. 
For example, if program A issues a LINK 
macro instruction specifying program B, the 
Contents Supervision routines will con- 



struct a new RB to represent program B's 
level of control. When program B has com- 
pleted its processing, control can pass 
back to program A. The supervisor uses the 
RB queue as a record of control levels; it 
can pass control to succeeding levels and, 
as the routines complete their operation, 
pass control back up the line, regardless 
of the number of times a task is 
interrupted. 

There are four types of RBs: 

• Program request blocks (PRBs) , which 
represent nonsupervisory routines that 
must be executed in the performance of 
a task. PRBs are created by the Con- 
tents Supervision routines that perform 
the Attach, Link, or XCTL functions. 

• Interruption request blocks (IRBs) , 
which control routines that must be 
executed in the event of asynchronous 
interruptions. IRBs are created in 
advance of an interruption by the CIRB 
routine at the user's request, but not 
placed on an RB queue until an inter- 
ruption actually occurs. 

• System interruption request block 
(SIRB) , which is used only for the sys- 
tem error task. There is only one SIRB 
in the system. 

• Supervisor request blocks (SVRBs), 
which represent supervisor routines. 
SVRBS are created by the SVC interrup- 
tion handling routines. They are 
queued just as PRBs are- 
Contents Supervision routines construct 

only one type of RB: namely, the PRE. 

The supervisor maintains a record of all 
programs in main storage — their attrib- 
utes, locations, and use statuses. This 
record is called the contents directory. 
The contents directory is made up of three 
separate queues (1) the link pack area con- 
trol queue (LPACQ) ; (2) the job pack area 
control queue (JPACQ) ; (3) the load list. 

The LPACQ is a record of every program 
in the system link pack area. This area 
contains reenterable routines specified by 
the control program or by the user. It is 
loaded by the nucleus initialization pro- 
gram. The routines in the system link pack 
area can be used repeatedly to perform any 
task of any job step in the system. In 
systems containing IBM 2361 Core Storage 
and Main Storage Hierarchy Support, a 
secondary link pack area may be constructed 
in hierarchy 1. 

The entries in the LPACQ are contents 
directory entries (CDEs). When a program 
represented in the LPACQ is requested for a 



task, it will be represented in that task's 
RB queue by a PRB; the address of this PRB 
will be inserted in the CDE. 

There is a JPACQ for each job step in 
the system that uses a program not in the 
link pack area. The JPACQ, like the LPACQ, 
is made up of CDEs. It describes routines 
in a job-step region brought into main 
storage by contents supervision routines to 
perform a task in the job step. The rou- 
tines in the job pack area can be either 
reenterable or not reenterable. Routines 
in the job pack area cannot be used to per- 
form a task that is not part of the job 
step. 

The load list represents routines that 
are brought into a job pack area or found 
in the link pack area by the contents 
supervision routines that perform the Load 
function. The entries in the load list are 
load list elements, not CDEs. Each load 
list element is associated with a CDE in 
the JPACQ or LPACQ; the programs repre- 
sented in the load list are thus also 
represented in one of the other contents 
directory queues . 



MAIN STORAGE SUPERVISION 

The MVT supervisor controls tasks 
through the TCB queue and the RB queues; it 
controls programs through the RB queues and 
the contents directoiry. A third major 
function, controlling main storage, is 
accomplished through a system of main 
storage queues. 

When the job management routines desig- 
nate a job step as a task, they request a 
region of main storage to be used in per- 
forming that task. The size of the region 
is specified by the user; the region con- 
tains the job pack area for the step, and 
all additional working space needed. 

All requests for main storage are 
handled by the GETMAIN SVC routine. The 
supervisor maintains main storage queues to 
reflect storage assignments; the GETMAIN 
routine simply adjusts these queues to 
reflect new assignments. 

When there are no job steps in the sys- 
tem, all of the dynamic area of main 
storage is treated as one region. It is 
represented to the supervisor by a free 
block queue element (FBQE) at the beginning 
of the area and a partition queue element 
(PQE) in supervisor queue space. The PQE 
contains the address of the FBQE, and 
therefore the address of the beginning of 
the free area; the FBQE contains the extent 
of the free area. When space is requested 
for a job step, the GETMAIN routine sub- 
tracts the requested area from the free 



area and builds a new FBQE and PQE for the 
new region. The address of the PQE is 
placed in the TCB of the job-step task. 

After job-step initialization, a program 
performing a task may request main storage 
by issuing the GETMAIN macro instruction. 
The GETMAIN SVC routine allocates the 
storage only within the region^ assigned to 
the job step being performed or within the 
supervisor queue area.^ The supervisor 
maintains a separate chain of queue ele- 
ments for allocation within a region. This 
chain keeps track of subpools within the 
region. A subpool is all of the main 
storage requested under a label called a 
subpool number. The storage in a subpool 
does not need to be contiguous. The chief 
advantages of subpools are that the storage 
is shared between tasks, and that all of 
the storage identified by a subpool number 
can be released with one FREEMAIN macro 
instruction. 

The supervisor FREEMAIN service routine 
is used to free main storage space when it 
is no longer needed to perform a task. 
Space assigned to a job step, space within 
a region, and space within the supervisor 
queue space are all freed by the FREEMAIN 
routine. The routine makes space available 
by adding elements to chains in which are 
recorded all free areas in main storage, 
and by adjusting the queues of allocated 
space. 

Main storage may be expanded by includ- 
ing IBM 2361 Core Storage in the system 
(excluding the Model 65 Multiprocessing 
System) . Main Storage Hierarchy Support 
for IBM 2361 Models 1 and 2 permits selec- 
tive access to either the processor storage 
(hierarchy 0) or 2361 Core Storage (hierar- 
chy 1) portions of main storage. If 2361 
Core Storage is not included and a region 
is defined to exist in two hierarchies, a 
two-part region is established within pro- 
cessor storage. The two parts are not 
necessarily contiguous. A hierarchy param- 
eter (HIARCHY=) in the GETMAIN and GETPOOL 
macro instructions permits specification of 
either hierarchy as desired. 



TIMER SUPERVISION 

The System/360 interval timer is a 32- 
bit word in lower main storage, that auto- 



^If the rollout feature is in the system 
and rollout can be performed, the GETMAIN 
routine can allocate space to the job step 
from a temporary region obtained through 
rollout . 

^Storage is allocated in the supervisor 
queue area only if the requester is a 
supervisor routine. 
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matically keeps decrementing as long as the 
system is running and the interval timer 
switch is on. The supervisor timer service 
routines enable the programmer to obtain 
the date and time of day, measure periods 
of time, or schedule activity for a specif- 
ic time of day. These routines, performed 
as a result of the macro instructions TIME, 
STIMER, and TTIMER, are handled just like 
any other SVC routines. 

The timer queue is a chain of timer 
queue elements; each element represents an 
interval request. These queue elements are 
constructed by the STIMER service routine. 
The chain is ordered so that the request 
for the next interval to expire is at the 
top of the queue. When a requested interv- 
al expires, a timer interruption occurs. 

The Timer Interruption Handler routine 
of the supervisor removes the top element 
from the timer queue and determines what 
action is to be taken. Examples are sche- 
duling a timer exit or making a task ready 
to be performed. 



CONSOLE COMMUNICATIONS AND SYSTEM LOG 

The console communications service rou- 
tines handle messages from a program to the 
operator or programmer, as well as messages 
from the operator to the system. The SVC 
routines WTO and WTOR (Write to Operator 
and Write to Operator with Reply) process 
the output messages from the system to the 
operator or to the programmer. Input comes 
from an external interruption, caused by 
operator intervention at the console. 

The system log consists of two data sets 
used by the system for recording statisti- 
cal information. The supervisor log sup- 
port routines perform input and output ser- 
vices related to the log. 

Multiple Console Support (MCS) , a system 
generation option, allows the selective 
routing of messages (WTO and WTOR) to one 
or more consoles, using routing codes 
assigned to each message and each console. 
When a graphic console or more than one 
non-graphic console is included with MCS in 
the system, a hard copy log is mandatory. 
The system log or any non-graphic device 
may be specified as the hard copy log. 



RECORDING AND USING CHECKPOINTS 

The supervisor provides routines to 
allow a job to be restarted after an 
abnormal termination. The Checkpoint rou- 
tine creates a series of records at points 
in the problem program where the programmer 
wishes a reexecution to begin. These rec- 
ords include a copy of the task's main 



storage region, descriptions of data sets, 
and system control information. The 
Restart routine uses these records to 
restore the task to main storage, mount, 
verify and position its data sets, and give 
it control at the point where the check- 
point entry was written. 



EXITING PROCEDURES 

The supervisor provides routines that 
prepare for the return of control from a 
completed program and perform the actual 
return of control. Control may return to a 
main-line program or to a supervisor rou- 
tine. The exiting procedures determine 
what type of program has completed its 
execution, and perform different clean-up 
operations for the different types. 

The Dispatcher routine is entered to 
return control to a program belonging to 
the highest priority ready task. The Dis- 
patcher, as we have previously noted, works 
through the TCB queue. (There is one case 
in which the Dispatcher is not entered to 
return control: when the completed program 
is a type-1 SVC routine that has not indi- 
cated the need for a task switch.) 



TASK TERMINATION 

The supervisor performs the processing 
needed when a task is terminated, either 
normally or abnormally. The termination 
processing includes releasing system 
resources that were assigned to perform the 
task. 

The End of Task (EOT) routine performs 
normal termination processing. Abnormal 
termination processing is performed by the 
ABTERM, ASIR, DAR, and ABEND routines. The 
ABDUMP routine provides a dump of TCBs and 
main storage related to the terminating 
task. 



SPECIAL FEATURES 

Time Slicing 

The time-slicing mechanism operates 
within the dispatcher. A priority is 
assigned to a group of tasks which are to 
be time-sliced; time-slicing occurs only 
among the tasks in the group and only when 
the priority level of the group is the 
highest priority level that has a ready 
task. Each task in the group is dispatched 
for the specified time slice. The dis- 
patching of tasks within the group con- 
tinues until all the tasks are waiting, or 
a task of higher priority than that of the 
group becomes ready. 



The group of tasks to be time- sliced, 
the length of the time slice, and the 
priority of the time-sliced tasks, will be 
specified by the installation. Any task 
inthe system that is not defined within the 
group to be time sliced will be dispatched 
under the current priority structure, i.e., 
when it is the highest priority ready task, 
cind until it either waits or a task of 
higher priority becomes active. 



Time Sharing Option 

The Time Sharing Option (TSO) adds gen- 
eral purpose time sharing to the facilities 
currently available with the MVT control 
program by enabling users at remote ter- 
minals to execute programs concurrently and 
to interact with those programs during 
execution. The installation can dedicate 
its system to time- sharing operations or it 
can run concurrent time-sharing and batch- 
processing operations. Including TSO in 
the control program does not restrict or 
limit batch operations. 

The Time Sharing Option consists of a 
control program (containing IBM-supplied 
service routines and command processors) 
and a number of IBM Program Products 
(available from IBM for a license fee) . 
The TSO control program, an extension of 
the MVT control program, accomplishes the 
following functions: 

• Identifies and verifies the time- 
sharing user. 

• Defines the user job. 

• Assigns the user job an amount of 
execution time (as determined by the 
installation- selected scheduling 
algorithm) . 

• Ensures a specified percentage of 
execution time for batch processing 
operations (when required) . 

• Transfers the user job between main 
storage and a direct access device 
(swapping) . 

• Logically reconnects the user job to 
the operating system when the job is 
swapped into main storage (called 
"restoring" the job) ; logically discon- 
nects the user job from the operating 
system before swapping out the user job 
(called "quiescing" the job). 

• Establishes and maintains communica- 
tions between the terminal user, his 
programs, and the TSO control program. 

• Handles attention interruptions from 
the terminal user. 



• Provides an optional set of SMF records 
for the TSO system, job and data mana- 
gement information, and optional system 
control task exits to installation- 
supplied routines. 

• Provides an optional record of the 
information that is passed to the Time 
Sharing Driver via the Time Sharing 
Interface Program from such TSO system 
routines as the Region Control Task, 
the Time Sharing Control Task, and the 
Time Sharing Dispatcher. 

Shared Direct Access Device 

The Shared Direct Access Device (Shared 
DASD) feature enables independently operat- 
ing data processing systems to share direct 
access storage devices- The two channel 
switch and its control commands, device 
reserve and device release , are the basis 
for control of direct access storage device 
sharing between systems. The shared DASD 
feature provides the control program func- 
tions needed to control device reservation 
and release. Essentially this feature con- 
trols the use of a serially reusable 
resource, the shared data and device. 

Rollout/Rollin 

Rollout/rollin allows the temporary, 
dynamic expansion of a particular job step 
beyond its originally specified region 
size. A job step's region size can be 
based on a minimum requirement, rather than 
a maximum. When a job step needs more main 
storage, this feature attempts to obtain 
unassigned storage; failing that, another 
job step is rolled out, that is, its entire 
region is transferred to secondary storage, 
and its storage is made available to the 
first job step. When released by the first 
job step, the additional storage is again 
available as unassigned storage, if that 
was its source, or to receive the job step 
to be transferred back into main storage 
(rolled in) . 

MVT with Model 65 Multiprocessing 

The multiprocessing feature, available 
with the Model 65, enables a single control 
program to use the productive capability of 
two CPUs (CPU A and CPU B) so that two 
tasks can be executed simultaneously. 

MVT with Model 65 multiprocessing can 
operate in two modes: multisystem mode and 
partitioned mode. In multisystem mode, all 
tasks are run under one control program. 
Both CPUs have access to all main storage 
and all I/O devices, except those devices 
that are suppojrted asymmetrically. Each 
CPU has its own UK-byte prefixed storage 
area (PSA) and can interrupt the other CPU 
through a direct hardware connection. 
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In partitioned mode, the two CPUs oper- 
ate as two independent systems. Each CPU 
must have its own copy of the MVT with 
Model 65 multiprocessing control program, 
main storage units, and I/O devices. 



Main Storage Hierarchy Support 

Main storage may be expanded by includ- 
ing IBM 2361 Core Storage in the system 
(excluding the Model 65 Multiprocessing 
System) . Main Storage Hierarchy Support 
for IBM 2361 Models 1 and 2, is a control 
program option that permits selective 
access to either the processor storage 
(identified as hierarchy 0) or 2361 Core 
Storage (identified as hierarchy 1) por- 
tions of main storage. If 2361 Core 
Storage is not included in the system and a 
region is defined to exist in two hierar- 
chies, a two-part region is established 
within processor storage- The two parts 
are not necessarily contiguous. Normally, 
all storage requested by programs of a 
given step or task is assigned from its 
region, although the rollout/rollin feature 
does provide the capability of acquiring 
temporary additional storage. If the Main 
Storage Hierarchy Support option has been 
selected, a region may be defined to con- 
sist of two parts: the first located in 
hierarchy and the second located in 
hierarchy 1. 



System Management Facilities 

System Management Facilities (SMF) is an 
optional feature of the control program. 
This feature can be selected at system 
generation. System Management Facilities 
gather and record information used to eval- 
uate system, data set, and direct access 
volume usage. SMF functions are performed 
by job management, input/output support, 
DADSM, and supervisor routines. The super- 
visor performs the following SMF functions: 



• Maintains a record of system wait time. 



• Assists in handling time limit 
expirations . 

• Counts and records references to user 
data sets. 

• Controls the output limit for SYSOUT 
data sets . 

• Records the number of 2048-byte blocks 
of storage assigned to a user program. 

For a detailed description of the implemen- 
tation of these functions, see Section 11, 
"Special Features." 



Tracing Facilities 

Two facilities, the Trace Table and the 
Generalized Trace Facility (GTF) , are pro- 
vided to assist in tracing program flow by 
monitoring and recording system events. 

Trace Table ; The Trace Table facility is 
an optional feature specified during system 
generation. The Trace Table routines place 
entries, each of which is associated with a 
certain type of event, in a trace table. 
The size of the table is also a system 
generation option; when the table is 
filled, the routine overlays old entries 
with new entries beginning at the top of 
the table. Trace Table entries are for- 
matted and printed out on SNAP dumps and 
stand-alone dumps. 

Generalized Trace Facility : The Genera- 
lized Trace Facility (GTF) is invoked as a 
system task when the operator issues the 
START command. When GTF is started, the 
operator selects specific events to be 
traced and may select to record the trace 
data either in main storage or on an 
external device. When the internal storage 
option is selected, the recorded data is 
comparable to that provided by the optional 
Trace Table facility. When the external 
device storage option is selected, the 
recorded data is more comprehensive. When 
GTF is active, the optional Trace Table 
facility, if present, is disabled. When 
the trace records are maintained in main 
storage, ABDUMP provides formatted trace 
data to abnormally terminated users when a 
SYSABEND DD statement has been included. 
When trace records are stored on an extern- 
al device, a trace EDIT function of 
IMDPRDMP can be used to provide the output 
of selected data. 



SUMMARY 

The supervisor is a collection of pro- 
grams for handling interruptions and pro- 
viding services for them. These interrup- 
tions are the basic method by which the 
control program manages data processing 
tasks. The supervisor functions are large- 
ly performed by routines that manipulate a 
network of control queues — the TCB queue, 
the RB queues, the contents directory, the 
main storage queues, and the timer queue. 

The processing after a timer/external, 
input/output, program, or machine interrup- 
tion is generally straightforward. Figure 
1-1 reflects what happens after one of 
these interruptions. The processing after 
an SVC interruption is a little more com- 
plicated. Figure 1-3 provides a more 
detailed, although still simplified, pic- 
ture of this processing. 
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Figure 1-3. Processing After an SVC Interruption 
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SECTION 2: INTERRUPTION HANDLING 



The supervisor handles all five types of 
interruptions . 

• For SVC interruptions, the supervisor 
determines what SVC service is 
required, and routes control to the 
appropriate service routine. 

• For timer/external interruptions, the 
supervisor determines the cause of the 
interruption and branches either to a 
timer service routine or to an external 
service routine. 

• For input/output interruptions, the 
supervisor branches to the Input/Output 
Supervisor, which performs input/output 
error handling and services. 

• For program interruptions, the supervi- 
sor determines whether the interruption 
is a monitor call request, or a program 
check. On monitor call requests, con- 
trol is returned directly to the user's 
program after GTF processing; on pro- 
gram checks, the supervisor either ter- 
minates the task in which the interrup- 
tion occurred, or branches to a user 
error handling routine. 

• For machine interruptions, the supervi- 
sor either places the machine in the 
wait state, or branches to an optional 
recovery management program. 



SVC INTERRUPTION HANDLING 

When a system or user program issues a 
macro instruction, the last machine 
instruction of the resulting macro- 
expansion at execution time is often an SVC 
instruction. The SVC instruction causes 
the computer to produce an SVC interrup- 
tion. The part of the supervisor that 
receives immediate control is called the 
SVC interruption handler. 

Main Functions 

The SVC interruption handlers perform 
the following main functions: 

• Save the register contents and SVC old 
PSW for the interrupted calling program 
or routine. 

• Requests the Generalized Trace Facility 
(GTF) , if GTF is active, or the option- 
al Trace Table facility (a system 
generation option) to record the 
interruption. 



In MVT with Model 65 multiprocessing, 
ensure that both CPUs do not perform 
disabled supervisor routines simul- 
taneously. 



Determine whether a supervisor request 
block (SVRB) should be constructed to 
restart the needed SVC routine if it is 
interrupted or if it must wait. 



If necessary, construct an SVRB, place 
in it information about the routine, 
and queue the SVRB to the request block 
queue for the current task. 



• Determine if the needed SVC routine is 
normally resident in main storage. 

• Pass control to a resident SVC routine. 

• Fetch a nonresident routine from auxil- 
iary storage and prepare for the pass- 
ing of control. 

• Defer a request for a routine that can- 
not be fetched. 

• When possible, restart deferred re- 
quests. 

In addition, the SVC interruption han- 
dlers perform two minor functions. They 
place in the so-called "environmental" 
registers the addresses of three control 
blocks needed by all SVC routines — the 
communications vector table, the current 
task control block, and the current request 
block. They also set up the return address 
to which the SVC routine will return con- 
trol when it is complete. 

The SVC interruption handlers are 
divided physically and functionally into 
two parts, the SVC First-Level Interruption 
Handler, (SVC FLIH) , and the SVC Second- 
Level Interruption Handler, (SVC SLIH) . 
The SVC First-Level Interruption Handler 
saves register contents and the SVC old 
PSW, and determines the type and location 
of the needed SVC routine. For certain 
commonly used SVC routines, the SVC FLIH 
also branches directly to the routine to 
begin its execution. For other SVC rou- 
tines, further processing by the SVC SLIH 
is needed. This processing includes the 
construction of a supervisor request block 
(SVRB) to control an interruptable routine, 
and the fetching of the routine if it is 
nonresident. 
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Saving the Status of the Interrupted 
Calling Routine 

The SVC interruption handlers must save 
the register contents and old PSW belonging 
to the calling routine. The purpose is to 
permit later return of control to the call- 
er at its next executable instruction. The 
current PSW, containing the address of the 
next executable instruction, is stored by 
the machine in hexadecimal location 20 in 
lower main storage. (Refer to IBM System/ 
360 Principles of Operation , section 
entitled "Interruptions.") The caller's 
register contents are saved by the SVC 
First-Level Interruption Handler in a spe- 
cial SVC save area in lower main storage, 
called lEASCSAV. Figure 2-1, parts A and 
B, show the saving of the caller's PSW and 
register contents, respectively, by the 
machine and by the SVC FLIH. 



The caller's register contents and old 
PSW remain in lower main storage or are 
moved to other save eireas, depending on the 
type of SVC routine that will be executed. 
If the routine is not allowed to issue, 
directly or indirectly, an SVC instruction, 
no SVC interruption can occur that would 
cause the saved status information to be 
overlaid. Accordingly, the caller's regis- 
ter contents and old PSW can safely remain 
in their lower main storage save areas. 
But if the needed SVC routine can cause a 
new SVC interruption, the status informa- 
tion can be overlaid and therefore must be 
moved to new save areas. Such overlaying 
of status information can occur if the SVC 
routine issues an SVC instruction, or a 
macro instruction that expands into an SVC 
instruction, or is interrupted and loses 
control to a routine of another task that 
issues an SVC instruction. 
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Ensuring That Both CPUs in a Model 65 
Multiprocessing System Do Not Perform 
Supervisor Routines Simultaneously 

In a multiprocessing system, the SVC 
FLIH routine determines whether the second 
CPU is performing a disabled supervisor 
routine by testing the supervisor lock and 
CPU affinity bytes in the multiprocessing 
CVT. If the lock byte is not set, neither 
CPU is performing a disabled supervisor 
routine. When one CPU obtains possession 
of disabled Supervisor code, the SVC FLIH 
routine sets the supervisor lock byte and 
places the CPUID in the CPU affinity byte. 
If one CPU tries to get possession of dis- 
abled Supervisor code, but finds the super- 
visor lock byte is set, the CPU tests the 
CPU affinity byte to determine which CPU 
set the byte. If set by the testing CPU, 
the SVC routine proceeds; if not, the SVC 
old PSW is set (that is, the SVC old 
instruction address is decremented by two 
or four) to reissue the SVC* instruction. 



If the SVC old PSW is enabled for 
external interruptions, the SVC* instruc- 
tion is reissued via the Type-1 SVC Exit 
routine, which restores registers and loads 
the SVC old PSW. The SVC* instruction is 
thus reexecuted until the CPU in possession 
of the lock byte releases it. 



If the SVC old PSW is disabled for 
external interruptions, the CPU that is 
executing disabled Supeirvisor code branches 
to the External FLIH routine so that 
external signals (such as a malfunction 
alert) from the other CPU can be received. 
The SVC* instruction will be reissued when 
the calling task is next dispatched. 
Before the External FLIH routine is 
entered, the status of the task that issued 
the SVC is saved. The registers are stored 
in the TCB, the current RB is set from the 
SVC old PSW to reissue the SVC instruction, 
the External FLIH bit is set in FLRETFLG to 
indicate that the registers have been 
saved, and the External old PSW is set 
equal to the SVC old PSW. The External 
FLIH routine tests the supervisor lock byte 
until the byte is unlocked. Between 
repeated tests of the lock byte, the CPU 
that is testing the byte is enabled for 
external interruptions. After the supervi- 
sor lock byte has been unlocked and any 
external interruptions which may have 
occurred have been processed, the External 
FLIH routine branches to the Dispatcher. 
When the calling task is dispatched, the 
SVC* instruction is reissued. 



♦Either an SVC instruction or an EXECUTE 
instruction that executes an SVC 
instruction. 



Determining Whether a Supervisor Request 
Block Is Needed 

The decision to create a supervisor 
request block depends on whether the needed 
SVC routine can issue an SVC instruction. 
Certain commonly used resident SVC rou- 
tines, called type-1 routines, are not per- 
mitted to issue an SVC instruction. Other 
types of routines are permitted to issue an 
SVC instruction. The SVC FLIH examines the 
SVC table to determine the type of routine 
that is needed. 



There are two parts in the SVC table, 
one containing entries for IBM-supplied SVC 
routines, the other containing entries for 
user-supplied SVC routines. The number and 
type of routines specified in the two parts 
depends on the particular system that the 
user generates at system generation time. 
There is one entry for each SVC routine. 
Each entry contains descriptive informa- 
tion, including a code showing SVC type, 
and the main storage or disk address of the 
SVC routine. 



Whether an SVRB need be constructed 
depends on the type of SVC routine. If the 
routine is a type-1, as indicated by a test 
of the SVC table entry, the SVC FLIH 
branches to the routine whose address is 
contained in the table entry. But if the 
routine is not a type-1, the SVC FLIH 
branches to the SVC SLIH to create a super- 
visor request block to hold the caller's 
register contents and to contain restart 
information for the SVC routine. 



An SVC routine may be restarted after 
any one of the following conditions has 
stopped or delayed its execution: 

• The routine issues an SVC instruction, 
thus causing an SVC interruption. 

• The routine is not resident and cannot 
be loaded; its request must therefore 
be deferred. 

• The routine is overlaid in a transient 
area block of main storage before it 
can be executed - 

• The routine may request a resource that 
is not immediately available, and is 
therefore placed in a wait condition 
pending the availability of the 
resource. 

In any of these cases, restart information 
— old PSW, wait count, etc. — is stored 
in the supervisor request block (SVRB) 
created for the routine by the SVC Second- 
Level Interruption Handler. 
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Constructing, Initializing, and 
Queueing the SVRB 

If the test of the SVC table entry (see 
Section 12, "Control Blocks and Tables") 
indicates that the needed routine is not 
type-1, and therefore that additional pro- 
cessing is needed, the SVC SLIH constinicts 
an SVRB from space it obtained the last 
time it was entered. The SVRB, when 
initialized with status and descriptive 
information about the SVC routine, will be 
queued to the request block queue belonging 
to the caller's TCB. If the SVC routine 
cannot be executed, or is interrupted by 
its issuance of an SVC, or cannot continue 
its execution, its entry point address or 
restart address, called the RB old PSW, 
will be stored in the SVRB by a supervisor 
routine. 

It is necessary for the caller's regis- 
ter contents and SVC old PSW, stored in 
lower main storage by the SVC FLIH, to be 
moved to safer areas in two request blocks. 
Since a non-type-1 routine may issue an 
SVC, the register contents and old PSW pre- 
viously saved may be overlaid by the regis- 
ter contents and old PSW of the calling SVC 
routine. To protect the original caller's 
status information, the SVC SLIH moves it 
from lower main storage to two request 
blocks, the caller's RB and the SVRB that 
is being constructed. As shown in Figure 
2-1, the SVC old PSW is moved from lower 
main storage to the PSW save area in the 
caller's RB. Since the caller's RB may 
lack a register save area, the caller's 
register contents are moved to the save 
area of the SVRB. Hereafter, if the cur- 
rently requested SVC routine itself causes 
a new SVC interruption, the SVC routine's 
register contents and old PSW may be saved 
in lower main storage with no harm to the 
■original caller's status information. 

The SVC SLIH queues the new SVRB to the 
head of the RB queue belonging to the cur- 
rent or caller's TCB. The order of request 
blocks on the RB queue determines the order 



in which the supervisor places into execu- 
tion routines started or requested for the 
given task. The request block at the head 
of the RB queue represents the routine that 
is next to be executed for its task. The 
SVC routine represented by the SVRB will be 
executed next for the current task. Then, 
when the supervisor's Exit routine has 
removed this SVRB from its RB queue, the 
new head or "current" RB will represent the 
interrupted routine or caller. The Dis- 
patcher will then restore the caller to 
execution, providing that there is no other 
ready task of higher priority. 

The SVC SLIH queues the SVRB to its RB 
queue by setting two pointers, one in the 
TCB, the other in the SVRB. The pointer* 
in the TCB points to the SVRB which is the 
■current" or head RB on the queue. The 
other pointer^ in the SVRB points to the 
previously current RB, which represents the 
caller of the SVC routine. (Refer to 
Figure 2-2.) 

The SLIH issues a GETMAIN macro instruc- 
tion to obtain storage to be occupied by 
another SVRB the next time the SLIH is 
entered. The resulting SVC interruption 
produces linkage to the GETMAIN routine of 
main storage supervision, which allocates 
the requested space. Since the GETMAIN 
routine is a type-1, no SVRB is added to 
the current task's RB queue, but status 
information belonging to the SVC SLIH is 
stored in lower main storage, as explained 
previously. 

The TCBATT flag in the current TCB is 
set to indicate that a system routine is 
executing and requires that this task not 
be interrupted by an attention exit for a 
time sharing task or by the STATUS SVC 
routine. 



*In this chapter certain terms are accom- 
panied by superscripts. The terms repre- 
sent fields of control blocks that are 
defined in Figure 2-3. 
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r - - n 
1 superscript 


Name of 

Control 

Block 

L _ J 


r - 1 

Formal 

Name 

of Field 


Common 
Field 


Name of 
(if any) 


1 Purpose of Field j 
_j _ J 


1 1 


TCB 




TCBRBP 









T~ - — — 1 

1 Points to current or top RB of RB queue.) 


1 2 


any RB 


RBLINK 








1 Points to next RB on RB queue. j 


1 3 


any RB 


RBFTP 








1 Indicates type of RB. j 


1 '* 


SVRB 


RBFNSVRB 








(Indicates whether SVRB is for a nonre- j 
jsident routine. j 


1 5 


ODE 


CDEPRGNM 


Program 


name 


I Contains the 8- character name of pro- j 
jgram represented by the CDE. j 


1 6 


any RB 


RBOPSW 


RB old 


PSW 




JThe entry point or restart address for j 
jthe routine controlled by the RB. | 


1 7 


CDE 


CDEEPADR 








1 Entry point address of module repre- | 
jsented by the CDE. | 


1 8 


TACT 


TTR 








(Relative track and record address of j 
(routine in a TAB. Used to identify thej 
(routine in the TAB. j 


1 9 


TACT 


FLAG 








(Indicates if TAB is being loaded or is j 
("free". ( 


1 10 


TCB 


TCBFLGS 








(Flags that indicate to the Dispatcher ( 
(that it may not place into execution j 
(any routine for the task. j 


1 11 


SVRB 


RBSVTTR 








(Contains relative track and record j 
(address of routine. j 


1 12 


SVRB 


RBTABNO 








(Displacement of TACT entry within the j 
(TACT. ( 


1 13 


TCB 


TCBGRS 


general register 
save area 


(Save area for general registers in a( 
[TCB. ( 


1 1*^ 


any RB 


RBWCF 


wait count 


field 


(When greater than zero, signals Dis- ( 
(patcher not to place into execution thej 
(routine controlled by the RB. j 


1 15 


none 


lEATCBP 


"new" TCB 


pointer 


(Indicates to the Dispatcher the TCB ( 
(whose current routine should next be j 
(dispatched. j 


1 16 


any RB 


RBSIZE 


length 


field 


(Contains the size of the RB in double ( 
( words . ( 



Figure 2-3. Control Block Fields Used by the SVC Second-Level Interruption Handler 



So far the SLIH has saved registers and 
the SVC old PSW in the appropriate RBs, and 
queued the SVRB to the TCB and to the pre- 
viously current RB. The SLIH next sets 
certain status bits in the SVRB. These 
status bits3 flag the request block as an 
SVRB and indicate that the associated SVC 
routine is nonresident , '^ even though a 
later test may prove that the routine is 
really resident. (The initial assumption 
is that the routine is nonresident.) The 



type of request block, as indicated by the 
status bits, determines the processing to 
be performed during the exiting procedure 
after the SVC routine has been executed. 

Determining if the SVC Routine Is Normally 
Resident in Main Storage 

The SVC SLIH must determine whether the 
needed SVC routine is normally in main 
storage and may be reached via a branch, or 
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whether the routine is normally nonresident 
and should be fetched from the SVC library. 
The SLIH makes the detejrmination by testing 
the "type" bits of the SVC table entry that 
was passed by the SVC FLIH. A type-2 rou- 
tine is resident in the nucleus; a type- 3 
or 4 routine is nonresident and is located 
in the SVC library, unless it has been pre- 
loaded into main storage by the Nucleus 
Initialization Program at IPL time. If a 
type 3 or type 4 SVC routine has been made 
resident, its entry in the SVC table is the 
same as that of a type 2 routine, and is 
accessed in the same manner. If the test 
of the SVC table entry reveals that the 
needed routine is resident in the nucleus, 
or is a type 3 or the first load of a type 
U routine preloaded into the link pack 
area, the SVC SLIH prepares for entry to 
the routine. The preparation consists of; 
placing in the SVRB a "resident routine" 
flag* to later inform the supervisor Exit 
routine that it need not perform exit pro- 
cessing for a nonresident routine, the 
restoring of standard input registers that 
the SLIH has altered, and the loading of a 
return address for use by the SVC routine 
when its execution is complete. The SLIH 
then branches to the routine address con- 
tained in the SVC table ent]:y. But if the 
test of the SVC table entry indicates a 
routine not resident in the nucleus, the 
SLIH branches to a part of its coding 
loosely termed the "transient area han- 
dler." The transient area handler's pur- 
pose is to determine the location of the 
routine and, if necessary, attempt to fetch 
the routine to a transient area block of 
main storage. 

Extended SVC Router (ESR) 



The primary function of the Extended SVC 
Router (ESR) is to provide linkage to 
Supervisor Service routines by logically 
extending the routing capability of the SVC 
Interruption Handlers. ESR accomplishes 
this via a secondary routing algorithm 
based on a parameter established prior to 
issuance of one of the ESR SVCs (116, 117, 
or 109) . The interface provided to the 
Supervisor Service routines invoked by ESR 
is identical to that provided by the SVC 
Interruption Handlers to Type 1, 2, 3, and 
4 SVC routines except for an additional 
parameter used by ESR for its routing. 

ESR Processing for Type 1 and 2 Supervisor 
Service Routines : The Type 1 and Type 2 
ESR Supervisor Routers are invoked via 
issuance of the Type 1 SVC 116 and Type 2 
SVC 117 respectively. Upon entry to SVC 
116 (Entry Point IGC116) or SVC 117 (Entry 
Point IGC117) , the ESR code in register 15 
is checked to insure that a corresponding 
function exists. If the ESR code does not 
represent a supported function, the invok- 
ing task is abnormally terminated. If the 



ESR code is valid, linkage to the appropri- 
ate resident supervisor service routine is 
accomplished by converting the ESR code 
received in register 15 to an index value 
into an internal branch table of V-type 
address constants. The appropriate V-con 
is loaded into register 15 and control is 
passed to the routine via a branch instruc- 
tion. Except for the use of register 15 
for input of an ESR code, these SVCs (116 
and 117) are identical to any other SVC 
routine. The same interface is presented 
to the Supervisor Service routines to which 
ESR is routing control as would have been 
presented to them by the SVC Interruption 
Handlers had they been invoked directly by 
an SVC number. 

ESR Processing for Type 3 and 4 Supervisor 
Service Routines ; The Type 3 and Type 4 
ESR Supervisor Service Router is invoked 
via issuance of SVC 109 (Entry Point 
IGC109). The ESR code in register 15 is 
checked to insure that it is not greater 
than the highest assigned number. If the 
ESR code is not valid, the invoker is 
abnormally terminated. Otherwise, the lin- 
kage to the appropriate supervisor service 
routine is accomplished by an XCTL to that 
routine. The XCTL parameters are developed 
by converting the ESR code passed in 
register 15 to a 3-character EBCDIC number 
which is appended to a prefix (IGXOO) to 
form an ESR name. For example, if the 
binary value in register 15 is 89, the 
resultant ESR name would be IGX00089. This 
ESR name represents the first load of an 
SVC and is used as input to the XCTL SVC. 
Control is now transferred to the module 
represented by the ESR name via an XCTL. 
Any subsequent loads of the Type 4 routine 
are named by incrementing the third and 
fourth characters of the original name. 
For example, several loads would be named 
IGX00089, IGX01089, and IGX02089. 

The Transient Area Handler 

Introduction ; The purpose of the transient 
area handler of the SVC SLIH is to monitor 
the transient areas of the nucleus and to 
fetch nonresident SVC routines from auxil- 
iary storage. If the desired routine is 
not in one of the transient areas, the 
transient area handler fetches the routine 
from the SVC library (SYSRES volume) and 
gives the routine control. If there is no 
available space in one of the transient 
areas for the desired routine, the tran- 
sient area handler makes the associated 
SVRB non-ready until space becomes 
available. 

Determining if the Desired Routine Is in 
the Link Pack Area of Main Storage ; The 
transient area handler first determines if 
the desired SVC routine has been preloaded 
into the link pack area (LPA) . The LPA 



Section 2: Interruption Handling 15 



contains reenterable modules from the link 
library and the SVC library that were pre- 
loaded at IPL time by the Nucleus Initiali- 
zation Program (NIP) . These modules remain 
resident until the next IPL. 

The transient area handler determines if 
the requested SVC routine is in the link 
pack area by searching the contents direc- 
tory entries = of the link pack area control 
queue for an entry which contains the name 
of the requested routine. The link pack 
area control queue contains entries de- 
scribing all programs that reside in the 
link pack area of main storage. (See Sec- 
tion 12, "Control Blocks and Tables," for 
the format and content of a contents direc- 
tory entry. For further information on the 
use of the contents directory, refer to 
Section 4, "Contents Supervision.") The 
name of the SVC routine used in the search 
is obtained from the interruption code that 
the machine stored in the SVC old PSW when 
the SVC instruction was executed. The old 
PSW now is in the request block belonging 
to the caller. The interruption code is 
converted to decimal and unpacked to pro- 
vide a four-character value to be used as 
the right half of the name. The left half 
of the name is a constant value, IGCO. 

Processing if the Routine Is in the Link 
pack Area ; If the requested SVC routine is 
in the link pack area, the transient area 
handler finds a contents directory entry in 
the link pack area control queue that con- 
tains the routine's name^. The transient 
area handler then extracts the routine* s 
entry point address'' from the contents 
directory entry and branches to the routine 
in the same way as with a resident SVC 
routine. 

Determining if the Routine Is Already in a 
Transient Area Block of Main Storage ; If 
the SVC routine is not in the link pack 
area, the transient area handler (location 
TARESTRT) first determines if the routine 
is already in a transient area block. If 
the routine is in a transient area block, 
it need not be fetched. There are at least 
two transient area blocks, each capable of 
containing one SVC routine. The number of 
transient area blocks, and thus the number 
of nonresident SVC routines that may be 
contained in the nucleus at one time, is 
specified during system generation. The 
transient area handler checks if the 
desired routine is in any of the transient 
area blocks by searching the entries of the 
transient area control table (TACT) for the 
routine name. (See Figure 2-U.) During 
its search, the transient area handler 
bypasses any TACT entry that indicates its 
transient area block is being loaded. 

The TACT (see Section 12, "Control 
Blocks and Tables") contains one entry for 



each transient area block. Each entry con- 
tains four words: the address of the tran- 
sient area block, the address of a "user 
queue" of SVRBs representing nonresident 
routines currently sharing a transient 
area, the relative track and record address 
(TTR) for the routine currently residing in 
the transient area block, and lastly the 
address of a TCB for a transient area fetch 
task (to be described later). 



Processing if the Routine Is Already in a 
Transient Area Block ; If the transient 
area handler determines from its search of 
the TACT entries « and the user queues, that 
the desired routine is already in a tran- 
sient area block, it performs as follows in 
order to bring the routine eventually under 
the control of the caller's TCB. The tran- 
sient area handler queues the SVRB for the 
requested routine to the user queue for the 
transient area block that contains the rou- 
tine. The SVRB is now a part of two 
queues, the RB queue belonging to the cal- 
ler's TCB and the user queue (also called 
the transient queue) for a particular tran- 
sient area block. Within the SVRB two dif- 
ferent pointer fields are used for the two 
queues. The RELINK field points to the 
next RB on the TCBs RB queue; the RBSVTQN 
field points to the next SVRB on the user 
queue. 

Each user queue contains SVRBs whose 
routines are or have been in a particular 
transient area block. There is one user 
queue for each block. Thus, if there are 
two transient area blocks, there are two 
user queues. The queues are built in the 
order in which routine requests are 
received. The requests are then serviced 
on a task priority basis. The purpose of 
each user queue is to permit the transient 
area handler to keep track of SVRBs whose 
routines are in a transient area block or 
have been overlaid in that block. 

After queuing the SVRB to a user queue, 
the transient area handler sets up the 
address of the transient area block as an 
entry point for a branch to the SVC rou- 
tine. It then loads the input registers, 
and branches to the transient area block to 
begin execution of the routine. 



Processing if the Routine Is not Already in 
a Transient Area Block ; If the search of 
the TACT entries and their associated user 
queues indicates that the desired routine 
is not already in a transient area block, 
the transient area handler performs as fol- 
lows. It rechecks the TACT entries' to 
find a transient area block that can be 
"used" (overlaid) by the requested routine. 
A transient area block can be "used" or 
overlaid in any of three cases; if it is 
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"free," if all of the user SVRBs for the 
transient area block are not "ready," or if 
the caller's task is of higher priority 
thcin that of the tasks whose SVRBs are 
"using" the transient area. 



A transient area is "free" if the rou- 
tine residing therein is not being executed 
for any task. A "User" SVRB for a tran- 
sient area is not "ready" if one or more 
nondispatchability bits^° are set in its 
TCB, thus preventing the dispatching of the 
routine for this task. The user SVRB is 
also not ready if it is not the top RB in 
the RB queue of its task. The top RB is 
always pointed to directly by its TCB. 



Preparation for the Overlaying of a Tran- 
sient Area ; If the transient area handler 
finds a transient area block that can be 
"used" or overlaid, it prepares for over- 
laying the area. It first places into a 
wait condition all using SVRBs whose rou- 
tine is in the transient area block. It 
does this for each SVRB by saving the cur- 
rent wait count and setting the number ' FF' 
in the wait count field of the SVRB. This 
is done for each SVRB on the user queue 
whose TTR field^^ equals the TTR field^ of 
the associated entry in the transient area 
control table. The saved wait counts, 
corrected for any intervening POST macro 
instructions, are later restored by the 
Transient Area Fetch routine during exiting 
procedures. (See "Loading the Routine.") 
If the routine in the located transient 
area block is not being executed, there are 
no using SVRBs, and therefore no need to 
place them into a wait condition. 

The transient area handler next prepares 
for the loading of the requested routine. 
It stores in the newly created SVRB the 
displacement *-2 of the TACT entry, thus 
avoiding a new search of the TACT. It also 
stores in this SVRB an RB old PSW pointing 
to the transient area block. This PSW will 
later be used by the Dispatcher to begin 
execution of the routine. The transient 
area handler then sets up the input regis- 
ters for the SVC routine and stores them in 
the caller's TCB^^, in preparation for 
later restoration by the Dispatcher when it 
causes entry to the desired routine. Pend- 
ing the loading of the routine into the 
available transient area block, the tran- 
sient area handler places the new SVRB into 
a wait condition (sets a wait count into 
its wait count field^**) . The wait condi- 
tion prevents the Dispatcher from starting 
execution of the routine supposedly in the 
transient area block but not yet loaded. 
The transient area handler also queues the 
new SVRB to the user queue for the tran- 
sient area block in order to keep track of 
the request for use of the block. 



The transient area handler determines 
the address of the next TACT entry after 
the one for the transient area block (TAB) 
to be loaded. It saves the address in a 
word, called TACTNEXT, in the transient- 
area-handler module. The TACTNEXT location 
will be used to start the search for a TAB 
for the next-requested transient routine. 
TACTNEXT originally contained the address 
of the first TACT entry. Its contents are 
modified each time a TAB is loaded for a 
new SVC request or for an XCTL request 
issued by a type-4 SVC routine. A type-4 
SVC routine is a nonresident routine that 
has more than one load module. It uses an 
XCTL macro instruction to cause linkage 
from one module to the next. 

Next, the transient area handler indi- 
cates to the Dispatcher that a task switch 
must occur. This is necessary because the 
loading of the SVC routine will be per- 
formed under the control of a transient 
area fetch TCB to load the desired routine 
from the SVC library. Although there is 
only one Transient Area Fetch routine, it 
may operate under the control of any of 
several high-priority transient area fetch 
TCBs. There is one such permanent TCB for 
each transient area defined during system 
generation. The minimum number is two. 

The task-switch indication to the Dis- 
patcher is necessary because the Dispatcher 
cannot otherwise dispatch the routine for a 
task of higher priority than the current 
task. The transient area handler indicates 
the need for a task switch by placing the 
address of the transient area fetch TCB in 
a "new" TCB pointer^ = in the nucleus. The 
transient area handler then branches to the 
Dispatcher, which restores registers and 
gives control to the Transient Area Fetch 
routine (TAHFETCH) to load the desired SVC 
routine. During the loading process, 
although the transient area fetch task is 
of extremely high priority, other lower 
priority tasks can be performed while the 
Transient Area Fetch routine is waiting for 
the completion of an I/O operation. 

Loading the Routine ; When the Transient 
Area Fetch routine (hereafter called the TA 
Fetch routine) is given control, a tran- 
sient area block is now "free" or able to 
be overlaid, as determined by previous pro- 
cessing. All SVRBs in the user queue for 
the transient area block are in a wait con- 
dition, including the SVRB which will soon 
control the awaited routine. The TA Fetch 
routine extracts the relative disk 
address^*- and length*- ^ of the SVC routine 
from the caller's SVRB, and places them in 
the control area for use by the supervi- 
sor's Program Fetch routine. The control 
area consists of a work area, an input/ 
output block (lOB) , and a channel program. 
The Program Fetch routine converts the 
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relative track and record address to an 
absolute disk address from which the SVC 
routine may be fetched. By use of the 
channel program, the Program Fetch routine 
transfers the desired routine from the SVC 
library to the available transient area 
block. If the BLDL or FETCH routine 
encounters a permanent I/O error, the TA 
FETCH routine recycles the BLDL or FETCH 
operation up to five times. The total 
count of recycles of BLDL and FETCH opera- 
tions for one use of the TA FETCH routine 
cannot exceed five. The recycle count is 
kept in the high order byte of the FETCH 
TCB address field of the TACT entry corres- 
ponding to the Transient Area Block; it is 
re-initialized after each use of the TA 
FETCH routine. If the permanent I/O error 
persists after five recycles of the BLDL or 
FETCH operation, the TA FETCH routine 
passes control to the Dynamic Device Recon- 
figuration SYSRES Effector, if DDR SYSRES 
support is in the system. DDR SYSRES 
returns control to the TA FETCH routine 
vd.th a return code of or 4. If the 
return code is 0, the BLDL or FETCH opera- 
tion is recycled again once. If the return 
code is 4, the task which requested the SVC 
routine is scheduled for ABEND with a com- 
pletion code of CO 6. If the renewed 
attempt to recycle the BLDL or FETCH opera- 
tion results in a permanent error, DDR SYS- 
RES is not invoked again. Instead, per- 
manent error processing takes place; the 
task which requested the SVC routine is 
scheduled for ABEND with a completion code 
of C06. 

If the time sharing option is operation- 
al in the the system, a TSEVENT macro 
instruction with the DONTSWAP operand is 
issued prior to FETCH or BLDL and FETCH 
processing. This indicates to the time 
sharing driver that a time sharing task 
cannot be swapped out of this time sharing 
region until FETCH or BLDL and FETCH pro- 
cessing is complete. When FETCH or BLDL 
and FETCH processing is complete (either 
successful or unsuccessful), a TSEVENT 
macro instruction with the OKSWAP operand 
is issued to permit the time sharing driver 
to resume swapping as necessary. 

If no I/O error has occurred during the 
fetch process, the TA Fetch routine makes 
ready all user SVRBs representing requests 
for the loaded SVC routine. The purpose is 
to allow the Dispatcher to eventually place 
the routine into execution under the con- 
trol of the user SVRB belonging to the 
highest priority ready task. In order to 
find all using SVRBs for the newly loaded 
routine, the TA Fetch routine searches the 
user queue belonging to the transient area 
block just loaded. The user SVRBs include 
both the SVRB associated with the current 
caller's task and SVRBs for other tasks. 
The copies of the SVC routine represented 



by the older SVRBs had previously been in 
execution and had been overlaid before 
their execution was complete. When the TA 
Fetch routine locates the using SVRBs for 
the currently loaded routine, it tries to 
remove the SVRBs from the wait condition. 
It does this by restoring the saved wait 
count, corrected for any POST macro 
instructions that have been executed while 
the SVRBs were waiting for the transient 
routine to be reloaded. 

The TA Fetch routine next dequeues and 
makes ready each SVRB on the request queue. 
This action later permits the transient 
area handler to determine if these SVRBs, 
whose requests had previously been 
deferred, may now be serviced. That is, 
the SVC routine just loaded may be the rou- 
tine needed for one or more of the deferred 
requests. 

To prevent redispatching of the TA Fetch 
routine, the TA Fetch routine places its 
own SVRB in a wait condition. This action 
is necessary, since the transient area 
fetch tasks have the highest priority in 
the system. The Dispatcher is thus pre- 
vented at its next execution from redis- 
patching the TA Fetch routine. 

The TA Fetch routine then branches to 
the Dispatcher, which passes control to the 
current routine of the highest priority 
ready task. This routine is represented 
and controlled by the RB to which the TCB 
points, called the "current" RB. The SVC 
routine just loaded will receive control 
when one of its user SVRBs or a deferred- 
request SVRB is the current RB for the 
highest priority ready task. The reader 
should note that the SVRB that controls the 
next execution of the loaded routine is not 
necessarily the SVRB most recently created. 
Task priority and readiness are the cri- 
teria that determine the order in which 
requests are serviced. 



Deferring the Request 

During its search of the TACT and the 
user queues, the Transient Area Handler 
routine may find that there is no available 
transient area block. That is, all tran- 
sient area blocks contain routines that are 
being executed; at least one user SVRB for 
each transient area block is ready; and the 
caller's task is not of higher priority 
than that of the tasks whose SVRBs are 
"using" the transient area blocks. With no 
transient area block available, the tran- 
sient area handler defers the current re- 
quest for the SVC routine. It does this by 
enqueuing the new SVRB to a special waiting 
queue called the request queue. The re- 
quest queue is a queue of SVRBs that are 
waiting for a transient area block to 
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become available. The request queue has a 
preassembled address called lEAQTAQ. 

The reader should note that an SVRB in a 
user queue or in the request queue is also 
in the RB queue belonging to the TCB of the 
calling or interrupted program. However, 
the pointer field of the SVRB is different 
in the two cases. 

The transient area handler defers the 
current request by queuing the new SVRB to 
the request queue* and by placing the SVRB 
into a wait condition (setting its RB wait 
count field greater than zero). It places 
in the SVRB an RB old PSW that points to a 
deferred-request restart point (TARESTRT) 
within the transient area handler. A 
branch is then made to the Dispatcher to 
give control to the current routine of the 
next highest priority ready task. 

Restarting Deferred Requests 

Deferred requests are restarted when the 
loading of an SVC routine is complete, or 
when the routine in a transient area block 
is no longer executed (becomes "free"). 
When either condition occurs, the SVRBs for 
deferred requests are dequeued from the re- 
quest queue and their wait condition reset 
(each RB wait count field is cleared to 
zero) . When one of the TCBs associated 
with the restarted SVRBs has the highest 
priority among the ready TCBs, the Dis- 
patcher returns control to the deferred- 
request restart point to begin the search 
of the TACT entries. The first check 
determines if the requested routine is 
already in a transient area block. Thus, a 
restarted deferred request is processed 
exactly like an original request. 

Minor Functions of SVC Interruption 
Handling 

Besides the major functions already 
described, the SVC interruption handlers 
perform two minor functions. One function 
consists of making available the addresses 
of three important control blocks for use 
by other supervisor routines during later 
processing of the SVC interruption. The 
other function is the loading of the return 
register with the address of the appropri- 
ate exit routine so that the SVC routine, 
when complete, can begin the return of con- 
trol to the caller by means of a simple 
branch, without the need for tests. 

Making Available Control Block Addresses ; 
The SVC First-Level Interruption Handler 
makes available to other supervisor rou- 
tines the addresses of three important con- 
trol blocks. It does this by placing in 



♦The queuing field is RBSVTQN. 



general registers 3, H, and 5, respective- 
ly, the addresses of the communications 
vector table (CVT) , the caller's TCB, and 
the current RB. The communications vector 
table contains addresses of resident con- 
trol routines and addresses of certain 
tables. These addresses are used by non- 
resident SVC routines. 

Preparing the Return Address for the SVC 
Routine: The return address is placed in 
the return register, general register 14, 
and depends on the type of SVC routine that 
will be executed. Type-1 routines, which 
are a commonly used non-SVC-issuing type, 
return control to the caller via the Type-1 
Exit routine. Other types of routines 
return control via the Exit routine. Since 
most SVC routines are type-1, the SVC FLIH 
initially assumes that the needed routine 
is type-1, and places in the return regis- 
ter the address of the Type-l Exit routine. 
If the FLIH later determines from the SVC 
table that the needed routine is not type- 
1, it branches to the SVC SLIH, which 
reloads the return register with a dif- 
ferent return address appropriate for all 
other routines. In this case, the return 
address is the location of an SVC 3 
instruction in the communications vector 
table. The SVC 3 instruction, when 
executed, causes a new SVC interruption and 
resultant linkage to the supervisor Exit 
routine. (For further information on the 
two supervisor Exit routines, refer to Sec- 
tion 9, "Exiting Procedures.") 



PROGRAM INTERRUPTIONS 

If the program being executed attempts 
an invalid action, a program interruption 
occurs and a code describing the attempt is 
stored in the program OPSW. Invalid 
actions causing program interruptions 
include using incorrect addresses, issuing 
invalid operation codes, and attempting to 
execute privileged instructions. Addition- 
al causes of program interruptions are 
fixed-point overflow, decimal overflow, 
exponent underflow, loss of significance 
and monitoring. With the exception of mon- 
itoring, these events may be masked out. 

The program interruption handler is 
automatically given control after any pro- 
gram interruption. An immediate branch is 
made to a Monitor Call Interrupt Handler 
routine to determine if the interruption 
was from either a System/370 or a System/ 
360 simulated Monitor Call instruction- If 
it is, the Generalized Trace Facility (GTF) 
routines are used to record the event and 
control is returned directly to the user's 
program. Otherwise, the interruption is a 
valid program check and GTF is used to 
record the interruption and return control 
to the Program Check FLIH to continue pro- 
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cessing. Upon return, it tests whether the 
interruption occurred in the supervisor or 
in user code, by examining the program 
OPSW. If the interruption occurred in the 
supervisor, control is passed to the ABTERM 
Prologue routine, which schedules abnormal 
termination of the task being performed at 
the time of the interruption. 

If the interruption occurred in user 
code, the supervisor tests the TCB for a 
program interruption element (PIE) address. 
A PIE is a control block associated with a 
user's error handling routine- If the user 
anticipates a program interruption and 
wishes to perform his own error handling, 
he issues a SPIE (set program interruption 
element) macro instruction. The SPIE ser- 
vice routine constructs a PIE and inserts 
its address in the TCB. 

If the supervisor finds no PIE address, 
that means that the user does not wish to 
perform error handling; the ABTERM Prologue 
routine is entered, as above. If the 
supervisor finds a PIE address in the TCB, 
it tests the high- order bit in the address. 
This bit is set to one whenever control is 
given to the user's error handling routine; 
if the supervisor finds it on when handling 
a program interruption, then a second pro- 
gram interruption has occurred in the error 
routine, and the task must be terminated. 

If a PIE exists and its high-order bit 
is zero, the supervisor tests whether the 
particular kind of program interruption 
that has occurred was specified by the user 
in the SPIE macro instruction. If it was, 
control is passed to the user's error 
handling routine. In a multiprocessing 
system, control is passed to the error rou- 
tine via the Dispatcher, so that the error 
routine can be bypassed if the task has 
been set nondispatchable by the second CPU. 
If it was not, control is passed to the 
ABTERM Prologue routine which, with the 
ABTERM routine, schedules the abnormal ter- 
mination of the task. The supervisor Exit 
routine is entered when a user error rou- 
tine completes its processing, and the 
interrupted program, via the Dispatcher, 
regains control. 



MULTIPROCESSING PROGRAM INTERRUPTION 
HANDLER 

If the Model 65 Multiprocessing System 
is in multisystem mode, the SSM instruction 
causes a program interruption. The system 
mask to be set is examined. If complete 
enablement is indicated, the supervisor 
lock and CPU affinity bytes in the multi- 
processing CVT are reset to zero only if 
originally set by the CPU that is executing 
the Program First-Level Interruption Handl- 
er. The interruption is recorded by GTF 



(if active) , before control is returned to 
the interrupted program with the system 
mask enabled. 



If complete enablement is not indicated, 
the supervisor lock and CPU affinity bytes 
are tested to determine which CPU is 
executing disabled Supervisor code. If 
neither CPU is performing a disabled rou- 
tine, the testing CPU sets the supervisor 
lock byte, and that CPU's ID is placed in 
the CPU affinity byte. The interruption is 
then recorded by GTF (if active) , and con- 
trol is passed to the interrupted routine 
with the system mask set as indicated. If 
the other CPU (not the testing CPU) is per- 
forming a disabled routine (supervisor lock 
byte set by other CPU) , the program inter- 
ruption old PSW is set (address is decre- 
mented) for reexecution of the SSM* 
instruction, and the system mask of the 
program interruption old PSW is examined. 



If the program interruption old PSW is 
enabled for external interruptions, regis- 
ters are restored, and the program inter- 
ruption old PSW is loaded. The SSM* 
instruction is thus reexecuted until the 
second CPU releases the supervisor lock 
byte. 



If the program interruption old PSW is 
disabled for external interruptions, the 
executing CPU branches to the External FLIH 
routine so that external signals (such as a 
malfunction alert) from the other CPU can 
be received. The SSM* instruction will be 
reissued when the calling task is dis- 
patched. Before the External FLIH routine 
is entered, the status of the task that 
issued the SSM instruction is saved. The 
registers are stored in the TCB, the cur- 
rent RB is set from the program interrup- 
tion OPSW to reissue the SSM* instruction, 
the External FLIH bit is set in FLRETFIX3 to 
indicate that the registers have been saved 
and the External old PSW is set equal to 
the program interruption old PSW. The 
External FLIH routine tests the supervisor 
lock byte until the byte is unlocked by the 
second CPU. Between repeated tests of the 
lock byte the CPU is enabled for external 
interruptions. After the supervisor lock 
byte has ^ been unlocked and any external 
interruptions which may have occurred have 
been processed, the External FLIH routine 
branches to the Dispatcher. When the cal- 
ling task is dispatched, it reissues the 
SSM* instruction. 



*Either an SSM instruction or an EXECUTE 
instruction that executes an SSM 
instruction. 
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If the interruption was not caused by an 
SSM instruction, the program FLIH routine 
determines if the second CPU is performing 
a disabled supervisor routine by testing 
the Supervisor lock and CPU affinity bytes 
in the multiprocessing CVT. If the lock 
byte is not set, the program FLIH routine 
sets the lock byte, places the CPUID in the 
CPU affinity byte, and the program FLIH 
routine proceeds as in MVT. If the lock 
byte was set by the testing CPU, the pro- 
gram FLIH routine proceeds. If the lock 
byte was set by the other CPU, it is tested 
until reset. Between repeated tests of the 
lock byte, the testing CPU is enabled for 
external interruptions by loading an 
enabled PSW so that the CPU can respond if 
the second CPU experiences a machine check 
and cannot reset the lock. Before the 
enabled PSW is loaded, a bit is set in a 
one-byte entry (FLRETFLG) in the prefixed 
storage area (PSA) to indicate that, if an 
external interruption occurs, the External 
FLIH routine is to return control to the 
program FLIH routine. This bit is reset 
when the program FLIH routine is able to 
set the supervisor lock byte and proceed. 



MODELS 91 AND 195 PROGRAM INTERRUPTION 
HANDLER 

For System/360 Models 91 and 195, and 
System/370 Model 195, the Program First- 
Level Interruption Handler (PFLIH) routine 
has been expanded to recognize decimal 
instructions, the TESTRAN interpreter, and 
imprecise interruptions. Depending on 
options selected at system generation time, 
the PFLIH routine may also include one or 
more of the following sections: 



A section to handle interruptions due 
to the presence of a decimal instruc- 
tion. 



control to the simulator to carry out the 
indicated operation.** 

If an error condition arises during the 
instruction-processing operations of the 
Decimal Simulator routine, control is 
returned to the PFLIH routine for deter- 
mination of how the condition is to be 
handled. 

If the Decimal Simulator routine is not 
in the operating system when a decimal in- 
struction interruption occurs, the PFLIH 
routine considers this to be an error con- 
dition and passes control to an appropriate 
error- handling routine (for example, to a 
user exit, to the TESTRAN interpreter, or 
to a system task-terminating routine) . 



Entry from the TESTRAN Interpreter 

On System/360 Models 91 and 195, and 
System/370 Model 195, when the TESTRAN 
interpreter is operating in either the 
"trace" or the "go-back" mode, it gives 
control to the PFLIH routine whenever a 
program interruption for a decimal instruc- 
tion is encountered. Prior to giving con- 
trol to the PFLIH routine, the TESTRAN 
interpreter sets a flag bit (the "return- 
to-TESTRAN" flag) to indicate that the 
interpreter is in use. The action that is 
taken by the PFLIH routine if the Decimal 
Simulator routine is not in the system has 
been described in the section, "Handling 
Decimal Instructions." 

If, because of an error, the Decimal 
simulator routine returns control to the 
PFLIH routine (and the TESTRAN interpreter 
had caused the PFLIH routine to be 
entered) , the "return- to-TESTRAN" flag is 
checked to verify the presence of the 
interpreter in the system, and control is 
returned to the TESTRAN interpreter for the 
handling of the error condition. 



• A section to provide for return to the 
TESTRAN interpreter if necessary. In 
the case of multiple-imprecise inter- 
ruptions, it is necessary that the SPIE 
macro instruction specify all possible 
types of interruption conditions. 



Handling Decimal Instructions 



EXTERNAL INTERRUPTIONS 

External interruptions are handled dif- 
ferently in uniprocessing and multiprocess- 
ing systems. In a uniprocessing system, 
the External First-Level Interruption 
Handler (FLIH) receives control after an 
external interruption. In a Model 65 



On System/360 Models 91 and 195, and 
System/370 Model 195, an operation- 
exception program interruption occurs when 
a decimal instruction is encountered in the 
execution of either a problem program or 
the TESTRAN interpreter. If the Decimal 
Simulator (lEAXDSOO) routine has been 
included in the operating system at system 
generation time, the PFLIH routine gives 



**A program interruption may be caused by 
an EXECUTE instruction that makes 
reference to a decimal instruction. If 
this is the case, the PFLIH routine con- 
structs, in a work area, a decimal in- 
struction that is equivalent to the orig- 
inal instruction as it would be seen by 
the hardware. 
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Multiprocessing System, if the two CPUs are 
operating in multisystem mode, the Second 
CPU Interruption Analysis routine receives 
control. Otherwise, the Second CPU Inter- 
ruption Analysis routine is bypassed, and 
the External FLIH routine receives control 
directly. 



UNIPROCESSING SYSTEM 

In a tiniprocessing system, the External 
FLIH routine saves the registers in the 
current TCB. If the System Management 
Facility is included in the system, control 
is then passed to the SMF Wait Time Collec- 
tion routine (described in Section 11) . 
This routine returns control to the Exter- 
nal FLIH routine. 

The External FLIH routine saves the ex- 
ternal old PSW in the current RB, and 
determines the cause of the interruption 
from the old PSW. If GTF is active, or if 
the Trace Table facility is present, the 
interruption is recorded by the tracing 
facilities. Control is then passed to the 
Timer Second-Level Interruption Handler if 
it is a timer interruption, or to the resi- 
dent External routine if it is an operator 
key interruption. 



MVT WITH MODEL 65 MULTIPROCESSING 

The Second CPU Interruption Analysis 
routine determines if the interruption was 
caused by one of the following conditions 
in the second CPU which requires immediate 
processing: 

• A machine-check interruption 

• An unrecoverable channel failure 

• A request to halt I/O that was started 
on the first CPU 

If a malfunction alert signal (issued by 
the CPU on which a machine check occurs to 
the other CPU) has caused the external 
interruption (determined from the external 
old PSW) , the Second CPU Recovery Manage- 
ment System Interface routine is entered. 
This routine tests a recovery management 
"time-out" flag in the PSA of the receiving 
CPU to determine whether both CPUs are mal- 
functioning. If so, the receiving CPU 
enters the wait state. Otherwise, the 
recovery management "time-out" flag is set 
in the PSA of this CPU, and an External 
Start (via a WRITE DIRECT instruction) is 
issued to the malfunctioning CPU, causing 
it to execute the Recovery Management Sup- 
port (RMS) routines. Before the External 
Start is issued, the supervisor lock byte 
is set for the malfunctioning CPU so that 



supervisor routines may be performed on 
that CPU. While that CPU performs the RMS 
routines, a completion flag (set when the 
malfunctioning CPU completes RMS) is 
tested. If the completion flag has not 
been set after a period of testing, the CPU 
waiting for the CPU to complete RMS enters 
the wait state. If the malfunctioning CPU 
is not in the wait state (that is, RMS was 
completed successfully) , control is 
returned to the Second CPU Interruption 
Analysis routine. 

If the external interruption was 
initiated by an RMS routine because of an 
unrecoverable channel failure on the second 
CPU (bit 3 of STMASK=1), the Second CPU 
Recovery Management System Interface rou- 
tine is entered. This routine operates as 
described above except that (1) an External 
Start is not issued since the RMS routine 
is already in process, and (2) the supervi- 
sor lock byte is not set since the RMS rou- 
tine has already set it. 

If a routine on either CPU requests a 
Halt I/O for I/O that was started on the 
other CPU, an external interruption is 
issued to the CPU on which the I/O was 
begun (via the First CPU signal routine) 
with an indication in STMASK (bit 7=1) 
that the Second CPU Halt I/O routine should 
be entered. The Second CPU Halt I/O rou- 
tine scans the UCB table to find each 
device which has been flagged for this CPU 
to perform Halt I/O and branches to the 
resident lOS routine. When Halt I/O has 
been completed, the UCB flag is turned off 
and the Halt I/O request flag in STMASK of 
the CPU on which the Halt I/O was requested 
is turned off. Control is returned to the 
Second CPU Analysis routine. 

If there are any other external inter- 
ruptions, the External FLIH routine 
receives control via a LOAD PSW instruc- 
tion. Otherwise, control is returned to 
the interrupted program. 

In addition to testing for operator key 
and timer interruptions, the External FLIH 
routine in MVT with Model 65 multiprocess- 
ing processes external interruptions which 
(1) occur during FLIH supervisor lock- 
testing routines when the CPU is enabled 
for external interruptions and (2) are 
caused by the second CPU (via a WRITE 
DIRECT instruction) . 

The External FLIH routine first deter- 
mines if a FLIH routine was interrupted by 
examining the PSA byte FLRETFLG. If a FLIH 
routine, other than External FLIH, was 
interrupted, registers are saved, and the 
interruption code is saved in a PSA byte 
RNEXCODE. Control is then returned to the 
interrupted FLIH routine. The I/O and Pro- 
gram Check FLIH routines exit to the Dis- 
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patcher which tests FLRETFLG for unpro- 
cessed external interruptions and, if there 
are any, gives control to the External FLIH 
routine. If (1) the External FLIH routine 
is entered because of an unprocessed exter- 
nal interruption or (2) if the External 
FLIH routine was in process at the time of 
interruption, the registers are not saved 
(having already been saved by External 
FLIH) , and the supervisor lock byte is 
tested and set. If a FLIH routine was not 
interrupted by the external interruption, 
registers are saved before the supervisor 
lock byte is tested. 

Prior to testing for timer, key or 
second CPU interruptions, the External FLIH 
routine tests the supervisor lock byte. If 
the lock byte is not already set, it is 
set, the CPUID is placed in the affinity 
byte, and the interruption is recorded by 
the Generalized Trace Facility (GTF) . If 
the lock has been set by the CPU that is 
executing FLIH, the FLIH routine continues. 
If set by the other CPU, the lock byte is 
tested until it is unlocked. Before each 
test, the testing CPU is enabled for exter- 
nal interruptions, and a bit in FLRETFLG is 
set to indicate that the interruption 
occurred during the External FLIH routine. 

In multisystem mode, the External FLIH 
routine also tests for external interrup- 
tions caused by the second CPU. The word 
STMASK in the PSA of the second CPU is 
examined, and control is given to the 
appropriate routine as follows: 



Bit set to 1 


Indication 




1 


Enter Dispatcher 




16 


QUIESCE 




17 


VARY CPU offline 




24 


Start I/O on Channel 
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In each case except VARY CPU offline, 
the STMASK bit is reset after execution of 
the appropriate routine, and the external 
FLIH is resumed. When all bits have been 
accounted for, control is passed to the 
Dispatcher. 



When an input/output interruption 
occurs, the Input/Output First-Level Inter- 
ruption Handler is automatically entered. 
Because the system may become enabled for 
input/output interruptions during the in- 
terruption handling, the Input/Output 
First-Level Interruption Handler may be 
entered again before the completion of the 
original interruption. To identify such a 
second entry, the original entry sets the 
I/O switch (lORGSW), which is tested 
whenever the interruption handler is 
entered. Only the first entry causes reg- 
ister saving and other initializing 
instructions; subsequent entries bypass 
these functions. 

If the System Management Facility (SMF) 
is included in the system, the input/output 
FLIH routine passes control to the SMF Wait 
Time Collection routine (described in Sec- 
tion 11) . This routine returns control to 
the Input/Output FLIH routine. 

In a Model 65 Multiprocessing System 
operating in multisystem mode, the supervi- 
sor lock and CPU affinity bytes are tested 
before the interruption is processed. If 
the lock byte is not already set, it is set 
by the CPU that is executing FLIH. This 
CPU also sets the CPU affinity byte. In- 
terruption processing continues. If the 
lock has been set by the other CPU, it is 
repeatedly tested until it is unlocked. 
Between repeated tests of the lock byte, 
the system is enabled for external inter- 
ruptions by loading an enabled PSW. Before 
loading of the enabled PSW, a bit is set in 
FLRETFLG to indicate to the External FLIH 
that control is to be returned to the 
Input/Output FLIH routine. This bit is 
reset after the lock byte has been set. 

Upon return from the Input/Output Super- 
visor, the pseudo- disable switch is tested. 
If off, control is passed to the Dispatch- 
er. If on, registers are restored and con- 
trol is returned to the interrupted routine 
by loading the input/output old PSW. In 
the multisystem mode, zeros are placed in 
the lock and CPU identity bytes if the sys- 
tem mask of the input/output old PSW is 
completely enabled. 



INPUT/OUTPUT INTERRUPTIONS 

The basic function of the supervisor in 
handling input/output interruptions is to 
branch to the Input/Output Supervisor. All 
input/output seirvices and error handling 
are performed within the Input/Output 
Supervisor. 



MACHINE INTERRUPTIONS 

There are three machine-check recovery 
programs and one channel error recovery 
program in OS/360 and OS/370. The availa- 
bility of each is dependent upon the CPU 
and the other recovery management pro- 
gram (s) selected. Figure 2-5 indicates the 
availability of each of these programs. 
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Figure 2-5. Availability of Machine-Check 
Programs 



The following two input/output recovery 
programs are not model dependent: 

• The Alternate Path Retry (APR) option,* 
which consists of two functions; sele- 
ctive retry, which is optional for MVT 
and standard for M65MP; and VARY PATH, 
which is standard for both MVT and 
M65MP. 

• The Dynamic Device Reconfiguration 
(DDR) option, which is not model- 
dependent but is automatically included 
for M65MP. 

When a machine check occurs, the pro- 
cessing varies according to the recovery 
option that the user has selected, as 
follows : 

• If no recovery program has been 
selected, the machine loads the machine 
check new PSW, and the CPU enters the 
wait state. ♦♦ 



If the SERO routine has been selected, 
the machine loads the machine check new 
PSW, and control is given to the resi- 
dent portion of the SERO routine to re- 
cord environmental data. When its 
function is complete, the SERO routine 
places the CPU in the wait state.** 



If the SERl routine has been selected, 
the machine loads the machine check new 
PSW, and control is given to the SERl 
routine. This routine records environ- 
mental data, and either abnormally ter- 
minates the job step affected by the 
machine check and causes the resumption 
of processing, or places the CPU in the 
wait state.** 



• If the Machine-Check Handler has been 
selected, the machine loads the machine 
check new PSW, and control is given to 
the Machine-Check Handler. This pro- 
gram records environmental data and 
attempts to recover from the machine 
check. If recovery is not possible, 
the Machine-Check Handler places the 
CPU in the wait state.** 

SERO, SERl, and the Machine-Check Handl- 
er format the information they collect in 
machine check records which they then re- 
cord on the SYSl.LOGREC data set. A 
description of the format and contents of 
the machine-check record for SERO and SERl 
is offered in Section 12. 

If the Model 65 Multiprocessing System 
is operating in multisystem mode, a machine 
check causes one CPU to send a malfunction 
alert signal to the other CPU. The sending 
CPU enters the wait state via the machine- 
check new PSW. When the malfunction alert 
signal is received by the other CPU, the 
Second CPU Recovery Management System 
Interface routine (see "External Interrup- 
tions") gets control on the receiving CPU 
and issues an External Start to the mal- 
functioning CPU. The External Start causes 
the malfunctioning CPU to execute the RMS 
routines . 

When a channel failure occurs, the I/O 
Supervisor passes control to the selected 
recovery program. Processing varies, 
depending on the recovery option that the 
user has selected, as follows: 



♦While it is not model -dependent, APR only 
performs its function usefully in a system 
with alternate paths and with the Channel- 
Check Handler. 



**The operator may then load the System 
Environment Recording, Editing, and 
Printing (SEREP) program to format and 
print the CPU logout area. The SEREP 
programs are model-dependent stand-alone 
diagnostic programs available for the 
Model 30 and for each higher numbered 
model. 
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• If no recovery program has been 
selected, the I/O Supervisor loads the 
machine check new PSW, and the CPU 
enters the wait state.* 

• If a SER routine or the Machine-Check 
Handler has been selected, the I/O 
Supervisor loads the machine check new 
PSW and control is given to the select- 
ed recovery program. The selected pro- 
gram records environmental data and 
then places the CPU in the wait state.** 

• If the Channel-Check Handler for models 
using the 2860, 2870, 2880, or System/ 
370 Models 145 or 155 integrated chan- 
nels has been selected, the I/O Super- 
visor branches to it for possible re- 
covery from the channel error condi- 
tion. This program performs two main 
functions. It provides an analysis of 
the channel logout information in the 
error recovery procedure interface 
block (ERPIB) to aid the appropriate 
device-dependent error recovery proce- 
dure in setting up for a retry of the 
failing operation by the I/O Supervi- 
sor. CCH also records environmental 
data about the channel error in a chan- 
nel error inboard record entry. This 
record entry is later written onto 
SYSl.LOGREC by the outboard recorder 
routine (OBR) of the I/O Supervisor. 

An operator awareness message is issued 
each time a channel error is recorded. 
(For a full description of the Channel- 
Check Handler, refer to the Input/ 
Output Supervisor PLM . 

When a permanent I/O error occurs, OBR 
passes control to Dynamic Device Reconfi- 
guration, if DDR is in the system. When a 
permanent I/O error occurs on a system 
fetch operation, TA FETCH, the error fetch 
sequence, or the DASD ERP passes control to 
DDR SYSRES, if DDR SYSRES is in the system. 
Both DDR and DDR SYSRES enable the operator 
to swap volumes on devices on which per- 
manent I/O errors have occurred. (The 
operator may also request a swap at any 
time with the SWAP command. ) 

Alternate Path Retry also aids in the 
recovery from I/O errors, indirectly, by 
allowing an I/O operation that has devel- 
oped an error on one channel to be retried 
on another channel. APR also allows the 
operator to VARY a path to a device online 
or offline. 



♦The operator may then load the System 
Environment Recording, Editing, and Print- 
ing (SEREP) program in order to format and 
print the CPU logout area. The SEREP pro- 
grams are model- dependent stand-alone dia- 
gnostic programs available for the Model 
30 and for each higher numbered model. 



For a full description of Dynamic Device 
Reconfiguration and Alternate Path Retry, 
refer to the Input/Output Supervisor PLM . 



SYSTEM ENVIRONMENT RECORDING 

System Environment Recording (SER) is a 
set of control program routines which re- 
cord hardware malfunctions of the Central 
Processing Unit and channels. There are 
two versions of SER, called SERO and SERl. 
At system generation the user may select 
one of these two versions. If he selects 
neither, the default option is used. The 
version which is used as the default option 
depends on the model (or models) specified 
and the size of the system. See System 
Generation . 

When a machine- check interruption occurs 
control is given to SER if that is the re- 
covery option selected. SER may also be 
entered by the SER interface of the I/O 
Supervisor if a channel error occurs. 

The less complex version of system 
environment recording, SERO, determines the 
type of malfunction and, if possible, 
writes a machine check record descriiiing 
the error on a data set called SYSl.LOGREC. 
This data set resides on the primary system 
residence volume. If SERO cannot write the 
record, the CPU is placed in a wait state 
and a message is printed to the operator to 
use SEREP. If the recording is partially 
or fully completed, the CPU is placed in a 
wait state and a message is printed to the 
operator requesting him to reload the 
operating system. 

The more complex version of System 
Environment Recording, SERl, also collects 
and writes out hardware environment data, 
but in addition, it performs selective ter- 
mination analysis which attempts to associ- 
ate the error with a specific task. If the 
error can be associated with a specific 
task and if the control program has not 
been damaged by the error, the task is ter- 
minated abnormally; if not, the CPU is 
placed in the wait state. 

When the SYSl.LOGREC data set is 90% 
full, a message is issued to the operator. 
The operator should then run the environ- 
ment recording edit and print (IFCEREPO) 
service aid. IFCEREPO formats the SYSl. 
LOGREC records, and then writes the records 
onto printer, tape, or disk, according to 
user specifications. IFCEREPO is described 
in the Service Aids Logic PLM . If the 
operator delays in recording the contents 
of the SYSl.LOGREC data set, it will even- 
tually become full; vdien it does, a message 
will be issued to the operator. He must 
then run IFCEREPO immediately, or system 
performance may be degraded. 
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SERO 

SERO collects, formats, and writes error 
information resulting from a machine check 
or from a channel error. The program is 
divided into two modules: the load nucleus 
resident module IFBSROOO, and the link 
library resident module, IFBSROXX (where XX 
is the model number — UO, 50, 65, or 75). 



LOAD NUCLEUS RESIDENT MODULE — IFBSROOO ; 
The resident portion of SERO is nonreusable 
and does not require Operating System/360 
facilities. The primary functions of this 
module are to halt all I/O activity and to 
read the first text record of the non- 
resident portion of SERO into an area which 
begins 32 bytes past the nucleus. 

If a machine check occurs, the resident 
module gains control directly from the 
machine-check new PSW. If a channel error 
is detected, the module is entered from the 
I/O supervisor which loads the machine- 
check new PSW. 

This module saves information to be used 
later by the non-resident portion of SERO 
in a 22-byte field in lower storage. After 
it has halted I/O on all devices, the 
module reads the first 1024 bytes of 
IFBSROXX into storage. If after ten re- 
tries, the resident module is not able to 
read IFBSROXX into main storage, it sets up 
the lOS wait state code OOOFOA and branches 
to the Bell Ring/Wait State module which 
sounds the console alarm and places the CPU 
in the wait state. The code OOOFOA is dis- 
played in the instruction counter. 

LINK LIBRARY RESIDENT MODULE — IFBSROXX ; 
Like IFBSROOO, the IFBSROXX module does not 
require any operating system facilities. 
There is an IFBSROXX module for each 
System/360 Model; the appropriate module is 
selected at SYSGEN time. 

After the module loads the remainder of 
itself into main storage, it checks loca- 
tion 50 to determine which type of error 
has occurred. This location is preas- 
sembled to X'FF". If the error is a 
machine check, location 50 is overlaid by 
the machine- check old PSW; a channel error 
does not change location 50. Once the type 
of error is established, the routine sets 
up the appropriate kind of record entry in 
which to place information about the error. 

The routine enables itself for machine- 
check interruptions. If it is already 
collecting error data and receives a 
machine-check interruption, the routine 
stops all data collection and writes out 
what it has accumulated up to that point. 
If a third error occurs, the routine cannot 
continue; it prints out an error message. 



If IFBSROXX was entered because of a 
machine-check interruption, the general 
purpose registers are checked for valid 
parity on all models except Model 40. 
Parity indicators are available for all 
registers except 13, 14, and 15 on Models 
50 and 75. Floating point registers are 
also checked for valid parity if the model 
is equipped with floating point. 

The routine checks the busy bit in each 
unit control block (UCB) to determine which 
I/O units were busy vdien the error 
occurred. The addresses of up to ten busy 
I/O devices are collected. The routine 
then fills in a record with the program 
identification, day, and time. After 
examining the seek address obtained from 
the header record of the SYSl.LOGREC data 
set, the routine writes on that data set 
the machine check record it has just 
created and an end-of-file record. 

If the routine records a partial or com- 
plete error record, it informs the operator 
by printing a message or displaying a code 
in the instruction counter. 

If the routine does not write an error 
record, it issues a message identifying the 
error. 



SERl 

Like SERO, SERl collects, formats, and 
writes error information resulting from a 
machine check or a channel failure. SERl, 
unlike SERO, is a single, serially reusable 
module that resides in the nucleus. In 
addition to writing error records, it 
attempts to identify the error with a spe- 
cific task. If a task/error relationship 
can be established, and if the control pro- 
gram is in no way damaged by the error, the 
task is terminated abnormally, but system 
operation continues. If, however, the 
error cannot be associated with a task, or 
if the control program is affected by the 
error, the system must be reloaded. 

SERl is entered in the same manner as 
the resident portion of SERO. It is 
entered as the result of either of the fol- 
lowing errors; 

1. A machine- check interruption. (The 
machine-check new PSW points to SERl.) 

2. A channel check (inboard). (lOS loads 
the machine-check new PSW- ) 

3. An external machine-check interruption 
on the Model 91, 95, and 195.* 



♦The 195 applies to both System/360 and 
System/370 models. 
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SERl checks location 50 to determine 
which type of error occurred. Location 50 
initially contains X'FF', which is overlaid 
by the machine-check old PSW if the error 
is a machine check. Location 50 is not 
changed if SERl is entered because of a 
channel error. 

SERl gathers error data into either a 
machine-check record entry or a channel- 
check record entry and writes the record on 
SYSl.LOGREC. SERl functions within the 
framework of the operating system; all I/O 
communication with the SYSl.LOGREC data set 
is via the EXCP macro instruction unless 
the control program was affected by the 
error. If the control program is damaged, 
SERl uses its own I/O routines. The DEB 
and DCB required when EXCP is used reside 
in the nucleus and are opened at IPL time 
by the nucleus initialization program (NIP). 

If SERl is able to associate the error 
with a task and the control program has not 
been damaged, SERl terminates that task by 
branching to the abnormal termination ser- 
vice routine, ABTERM. When control returns 
from ABTERM, SERl re-initializes itself and 
branches to the Dispatcher so that the sys- 
tem can continue. 

If the SERl routine determines that only 
a job step need be terminated, it performs 
the following processing: SERl sets all 
TCBs in the system nondispatchable, except 
certain system TCBs, and sets the "system 
must complete" flag in the current TCB. 
The system tasks that remain dispatchable 
are: the communications task, the rollout/ 
rollin task (if that feature is present) , 
the system error task, and the transient 
area fetch task. The SERl routine then 
halts all input/output activity associated 
with the current TCB. It writes the error 
environment data on the SYSl.LOGREC data 
set and writes an error message to the 
operator. The TCBs are then made dispatch- 
able and the ABTERM routine is entered for 
the job step that was affected by the fai- 
lure. When control returns from the ABTERM 
routine, the SERl routine branches to the 
Dispatcher. 

Thus, the requirements for system con- 
tinuation are task/error relationship, a 
complete record of the error, and success- 
ful termination of the task. In the fol- 
lowing cases, these requirements are not 
met, so the system must be reloaded. 

1. An additional machine-check occurs 

while SERl is handling an error. Data 
collection on the original error 
stops, and SERl attempts to write a 
partial record on SYSl.LOGREC. The 
partial record contains the informa- 
tion gathered up to the time the 
second error occurred. 



2. A complete record was written, but the 
error could not be associated with a 
specific task. 

3. A complete record was written, but the 
control program was affected by the 
error. 

t. The control program was damaged by the 
error and a complete record could not 
be written. 

In any of these cases, a message is printed 
on the primary output device instructing 
the operator to reload the operating sys- 
tem, and SERl places the system in the wait 
state. 

Models 91, 95, and 195 can be inter- 
rupted by a special machine check called an 
external machine check. The SERl routine 
for these models is given control when an 
external machine check occurs. If the sys- 
tem mask in the machine-check old PSW is 
not all ones, the data (record) associated 
with the machine failure is saved in the 
SERl buffer area, and an internal indicator 
that a record has been saved is set. Con- 
trol is then returned to the point of in- 
terruption. The record that SERl saves is 
recorded on the SYSl.LOGREC data set if the 
next SERl entry is caused by either a chan- 
nel failure or a CPU (normal machine check) 
failure. 

• If this next entry is due to a channel 
failure, the channel-failure record and 
the saved external machine- failure rec- 
ord are processed as one record on the 
SYSl.LOGREC data set, and the operating 
system causes a termination of the pro- 
blem program as for a channel failure. 

• If, instead, the next entry is due to a 
CPU failure, the CPU-failure record is 
recorded first on the SYSl.LOGREC data 
set, and then the external machine- 
check record is recorded on the same 
data set. The normal SERl techniques 
of handling a CPU failure are then per- 
formed. That is, either the task or 
the system is terminated. 

However, if the next entry to SERl is 
due to an external machine check, the data 
associated with the first failure is lost, 
and an entry is made in the count of the 
number of consecutive external machine 
checks experienced. If the count reaches a 
value of ten, a record with the count value 
is written on SYSl.LOGREC, and the system 
is terminated. 

If the initial check of the system mask 
in the old PSW (see preceding) showed that 
the mask was all ones, the SERl routine is 
placed in a waiting loop until all input/ 
output interruptions in the system have 
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been serviced. If a channel failure 
occurs, the SERl routine processes both the 
channel failure and the external (I/O) fai- 
lure as a single record and terminates the 
system in the manner normally done for 
channel failures- If there are no channel 
failures and all the I/O interruptions are 
taken care of, the SERl routine processes 
the external machine-check record and the 
system continues from the point of 
interruption. 

System Environment Recording with Multiple 
Console Support 

The SER routines use WTO (SVC 35) macro 
instructions cind SIO instructions to write 
messages to operator consoles. When 
operating with MCS, a WTO macro instruction 
(SERl only) contains a routing code of 1 in 
the expansion, and the message is routed to 
the master console. 

When using an SIO instruction, the mas- 
ter console is located using the communica- 
tion task control tables. When the master 
console is a composite, a list of CCWs is 
constructed to write a message to the con- 
sole. When the master console is a 1052 or 
a 2250, a CCW to ring the console alarm is 
added to the list. If the master console 
is not a 1052, 2250, 2740, or a composite 
console, no message is written. 

After the SIO instruction has been 
issued, the device for the hard copy log is 
located. If it is the SYSLOG or a 2250, no 
message is written. If it is a 1052 or a 
2740, the message is written but the alarm 
is not rung. For either case, the appro- 
priate WAIT code is loaded into register 
and an LPSW instruction puts the system 
into a wait state. 



MACHINE-CHECK HANDLER (MCH) 

This program is optional for the System/ 
360 Model 65 and standard for the Model 65 
Multiprocessor, the Model 85, and for all 
models of System/370. The Machine-Check 
Handler consists of a resident routine 
which always remains in main storage and of 
transient modules which reside in the SYSl. 
SVCLIB data set. The program attempts to 
recover from the cause of the machine-check 
interruption and record as much information 
as possible about the malfunction. 

For the Model 65, MCH first determines 
if the instruction that was being executed 
when the machine check occurred can be 
retried, and, if this is possible, retries 
it. This step is handled by machine recov- 
ery facilities in the System/360 Model 85 
and the System/370 Models 145, 155 and 165. 



If, however, instruction retry is not 
possible, MCH tries to repair program 
damage. The program damage may be asso- 
ciated with either a defective storage pro- 
tection feature (SPF) key or a defective 
main storage location. In some models, the 
Machine-Check Handler is able to correct 
defective SPF keys or damaged code in main 
storage. 

If program damage can be repaired, the 
Machine-Check Handler attempts to retry the 
interrupted instruction. If the retry is 
successful, the Machine-Check Handler has 
recovered completely from the machine-check 
interruption . 

If program damage cannot be repaired or 
instruction retry is unsuccessful, the 
Machine-Check Handler can either continue 
partial system operation or place the CPU 
in the wait state. The choice depends on 
the type of task that was current at the 
time of the machine interruption, the num- 
ber of tasks that are affected, and the 
extent of the program damage. If limited 
system operation is possible, it either 
abnormally terminates the current job step 
or sets the current task nondispatchable. 
However, in the Model 65 Multiprocessing 
System, the current task is not set nondis- 
patchable in the event of a solid storage 
failure. Instead, the Storage Reconfigura- 
tion facility schedules a selective ABEND* 
for that task, and logically removes the 
failing storage from the system. If possi- 
ble, system operation is resumed. 

If even limited system operation is not 
possible because a critical system task is 
permanently damaged, the Machine-Check 
Handler issues an error message and places 
the CPU in the wait state. The operator 
may then load the SEREP program to format 
and print diagnostic information from the 
CPU logout area. 

For a complete description of the 
Machine-Check Handler program consult the 
manual appropriate for the model being 
considered. 

• Machine-Check Handler for the Model 65 



• 


PLM. 

Machine-Check Handler for 


the 


Model 85 


• 


PLM. 

Ma chine- Check Handler for 


the 


System/ 




370 Models 135 and 145. 


the 




• 


Machine-Check Handler for 


System/ 



370 Models 155 and 165 PLM. 



♦A selective ABEND may result in unclosed 
data sets . 
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SECTIONS: TASK SUPERVISION 



Task Supervision consists of allocating 
a requested service for a particular task. 
Task Supervision may be divided into three 
categories: services directly related to a 
task control block, services indirectly 
related to a task control block, and ser- 
vices internal to the supervisor. 

Services directly related to a task con- 
trol block (TCB) involve the creation, 
manipulation, or elimination of a TCB. 
These services consist of: 

• Attaching a subtask. 

• Changing the dispatching priority of a 
task. 

• Extracting information from a task con- 
trol block. 

• Detaching a subtask. 

Services indirectly related to a task 
control block consist of: 

• Specifying a program interruption exit 
routine. 

• Synchronizing a program with one or 
more events. 

• Serializing the use of a resource. 



The caller may request, via the CHAP 
macro instruction, that the dispatching 
priority of its own TCB or of one of its 
subtask TCBs be changed. The dispatching 
priority determines the order in which the 
supervisor's Dispatcher places into execu- 
tion routines for competing tasks. The 
CHAP routine computes a new dispatching 
priority, tests the legality of the result, 
places a dispatching priority value in the 
specified TCB, queues the TCB to a new 
position in the TCB queue, and tests wheth- 
er the current routine of the priority- 
altered TCB should receive control in place 
of the caller. 

Specified information may be extracted 
from a particular TCB. The TCB is the cal- 
ler's or one of its subtask TCBs. The con- 
trol information, obtained via the Extract 
routine, is placed in a table whose address 
is provided as an operand of the EXTRACT 
macro instruction. 

The detaching of a subtask TCB from its 
parent TCB's subtask queue is the final 
step of normal or abnormal termination of 
the subtask. The Detach routine also frees 
storage areas belonging to the subtask. 
The storage areas include the subtask TCB 
itself and any associated problem-program 
register save area. 



• Scheduling an asynchronous exit rou- 
tine. 

Services internal to the supervisor con- 
sist of: 

• Testing and indicating the need for a 
task switch. 

• Testing the validity of user-supplied 
addresses . 



SERVICES DIRECTLY RELATED TO A TASK CONTROL 
BLOCK 

The attaching of a subtask, requested 
via the ATTACH macro instruction, consists 
of the creation of a TCB to represent the 
subtask, the placing of control information 
in the new TCB, the allocation of main 
storage to the subtask, the placing of the 
new TCB on two TCB queues, and the sched- 
uling of linkage to contents supervision to 
obtain the program to be first executed for 
the new task. When the new TCB is highest 
priority among the ready TCBs, the speci- 
fied program is given control. 



ATTACHING A SUBTASK 

A user or system routine issues an 
ATTACH macro instruction to cause the 
supervisor to begin the execution of a spe- 
cified program as a subtask of the caller' s 
task. As a subtask, the specified program, 
and other programs later invoked via LINK 
and XCTL macro instructions, can compete 
for CPU time and can use resources already 
allocated to the caller's task. The ATTACH 
macro instruction, when executed as a 
macro-expansion, causes an SVC interrup- 
tion. The interruption handling routines 
branch to the Attach SVC routine to perform 
the requested service. 

The Attach routine performs the follow- 
ing main functions: 

• Obtains storage space for a new TCB- 

• Places in the new TCB information 
needed to control the subtask. 

• Allocates to the subtask subpools of 
main storage belonging to its parent 
task. 
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• Places the address of the new TCB on 
two lists: 

- the subtask queue of its parent task. 

- the TCB queue used by the Dispatcher. 

• Schedules linkage to contents supervi- 
sion to locate the first program to be 
executed for the new subtask, fetch the 
program if necessary, and schedule its 
execution. 

While performing the main functions, the 
Attach routine also performs certain minor 
functions: 

• If the ATTACH macro instruction con- 
tains the ETXR operand, storage space 
is obtained for one or two control 
blocks (IQE, IRE) to be used for the 
scheduling and controlling of an end- 
of-task exit routine - 

• Places control information in these 
control blocks. 

• Decides whether the parent task or the 
new subtask will receive control next 
from the Dispatcher. In a Model 65 
Multiprocessing System, the new subtask 
may receive control on either CPU. 

The TCB that is created will be initial- 
ized by the Attach routine to contain sta- 
tus information and list origins for queues 
needed by program being executed for the 
subtask. For example, the TCB will contain 
a pointer to the top RB on the RB queue, 
representing the currently executing pro- 
gram for this TCB. (See Section 12, "Con- 
trol Blocks and Tables," for a detailed 
description of the TCB fields.) 

Obtaining Storage Space 

The Attach routine first tests the 
recursion bit in the TCBNSTAE field. If 
the recursion bit is on, an ATTACH macro 
instruction has been issued in the Specify 
Task Abnormal Exit (STAE) exit routine. 
This is an invalid action, and a four is 
placed in register 15 to indicate that the 
ATTACH request has not been serviced. The 
Attach routine exits by returning control 
to the Dispatcher. 

If the ATTACH was not issued by the STAE 
exit routine, the Attach routine next 
determines the amount of storage needed for 
the new task. 

The storage must include space for the 
new TCB, and optionally space for one or 
two control blocks used to schedule and 
control an end-of-task exit routine for the 
subtask. The control blocks are an inter- 
ruption request block (IRB), used to con- 
trol the execution of the exit routine, and 



an interruption queue element (IQE) , which 
helps schedule the execution of the rou- 
tine. (See the section "Scheduling User 
Exit Routines.") 

The amount of storage space that the 
Attach routine must allocate depends on two 
factors: whether the ETXR (end-of-task 
exit request) operand has been specified in 
the ATTACH macro instruction, and whether 
an interruption request block (IRB) already 
exists for the specified exit routine. If 
the ETXR operand is not specified, the 
Attach routine needs space only for a new 
TCB. For this purpose it issues a GETMAIN 
macro instruction for 216 bytes from sub- 
pool 253, supervisor queue space. If the 
ETXR operand has been specified and an 
intermiption request block (IRB) already 
exits for the exit routine, space for a TCB 
and for an interruption queue element (IQE) 
— a total of 232 bytes — is similarly 
obtained from subpool 253. But if the ETXR 
operand has been specified, and an IRB does 
not already exist for the desired exit rou- 
tine, the Attach routine obtains space for 
an IRB, a TCB, and an IQE. It does this by 
issuing a CIRB (Construct IRB) macro 
instruction with the WKAREA=29 parameter, 
which requests the CIRB routine to obtain a 
work area of 29 doublewords in addition to 
space for an IRB. The additional space is 
used for the TCB and the IQE. The CIRB 
routine is also called stage one of the 
exit effector (refer to "Scheduling User 
Exit Routines.") 

The Attach routine determines in the 
following manner whether an interruption 
request block (IRB) already exists, and 
therefore whether it should, via the CIRB 
routine, create a new IRB. (Refer to 
Figure 3-1.) The Attach routine searches 
the subtask queue belonging to the caller's 
TCB, looking for a subtask TCB which 
indirectly points to the same end-of-task 
exit address as that specified in the cal- 
ler's ATTACH macro instruction. A sub- 
task's exit- routine address is determined 
indirectly via the TCBIQE field of the sub- 
task's TCB. The TCBIQE field points to an 
interruption queue element (IQE) , if one 
has been created for the subtask. If the 
TCBIQE field is zero, this subtask has no 
IQE, and thus no end-of-task exit routine 
has been requested for the subtask. The 
next subtask TCB on the subtask queue is 
then examined. If a subtask' s TCBIQE field 
is not zero, it points to an IQE, which 
points to an IRB, which points to an end- 
of-task exit routine for the subtask. If 
the exit-routine address in the subtask' s 
IRB is equal to the end-of-task exit 
address specified in the caller's ATTACH 
macro instruction, an IRB for the desired 
exit routine already exists. In this case 
the Attach routine need not create a new 
IRB. 
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Subfask Queue: TCB's Belonging fo Subfasks of the Caller's Task 




Figure 3-1. Queue Relationships among a 
TCB, IQE, IRB, and End- Of - 
Task Exit Routine 



If the Attach routine finds that an IRB 
does not already exist for the specified 
exit routine, it issues a CIRB macro 
instruction to cause a branch to the CIRB 
(Construct IRB) routine. This routine 
obtains space for an IRB, initializes the 
IRB, and obtains a register save area for 
the end-of-task exit routine. Space for 
the new subtask's TCB and for the interrup- 
tion queue element (IQE) is obtained as an 
extended save area belonging to the IRB. 
After control is returned to the Attach 
routine, it reduces the size of the IRB and 
uses the extended save area to build the 
TCB and the IQE. 



Initializing the IQE, IRB, and TCB 

If storage for an IQE was obtained, the 
Attach routine initializes the fields of 
the IQE as shown in Figure 3-2. 

Besides initializing the IQE, the Attach 
routine increases by a count of one a "use" 
count (RBUSE) . This use count indicates 
the number of subtasks that use the same 
IRB to schedule and control an end-of-task 
exit routine. The supervisor Exit routine 
decreases the use count by a count of one 
each time that the end-of-task exit routine 
completes its execution. When the use 
count becomes zero, the supervisor Exit 
routine frees the storage space occupied by 
the IRB. 

Note ; If the ATTACH macro instruction was 
issued with the STAI operand, a subtask 
ABEND intercept (STAI) SCB is created, and 
any STAI SCBs queued to the TCB of the 
requesting program are propagated to the 
new subtask TCB. 

The Attach routine initializes the newly 
created subtask TCB by first clearing all 
areas except the register save area, then 
placing needed information in the TCB. If 
the ETXR operand was included in the call- 
er' s ATTACH macro instruction, the address 
of the IQE is placed in the TCB (TCBIQE 
field) , and a flag is set to indicate that 
an end-of-task exit routine has been 
requested. 

The Attach routine does not propagate 
the JOBLIB field if TASKLIB=dcb address was 
specified. Instead, the TASKLIB deb 
address is placed in the JOBLIB field. 

Propagating Fields from the TCB of the 
Attaching Program 

After initializing the newly created 
subtask TCB, the Attach routine transfers 
(propagates) from the caller's TCB to the 
new TCB certain fields that are the same in 
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Figure 3-2. Initialization of the Interruption Queue Element 
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all TCBs within a job step. These fields 
include a pointer to the partition queue 
element (TCBPQE) (see Section 5, "Main 
Storage Supervision"), a pointer to the 
task I/O table (TCBTIO) , and a pointer to 
the DCB for the job library (TCBJLB) . If 
the System Management Facility is included 
in the system, a pointer to the timing con- 
trol table (TCBTCT) is also propagated. 

Placing Parameter Information in the Fields 
of the Subtask TCB 

After unchanged information from the 
caller's (attaching) TCB has been trans- 
ferred to the new subtask TCB, information 
from the input parameters of the ATTACH 
macro instruction is placed in the subtask 
TCB. This infonnation includes the super- 
visor mode bit, if needed; the address of 
an event control block (ECB), if specified; 
the limit and dispatching priorities for 
the new subtask; the "nonrolloutable count" 
field (TCBNROC); the TCBFRA flag; the 
initialization of the TCBJSTCB field; the 
initialization of the TCBJPQ field; the 
initialization of the protect key field 
(TCBPKF) , if needed; the initialization of 
the save area pointer (TCBFSA) , if needed; 
the initialization of the pointer to the 
SPQE chain (TCBMSS) , if needed; and the 
address of a job step control block ( JSCB) . 

If the event control block (ECB) parame- 
ter has been specified, the Attach routine 
checks the validity of the ECB address, and 
if valid, places the ECB address in the 
TCBECB field of the new TCB. If the ECB 
address is invalid — does not specify a 
fullword boundary or violates storage pro- 
tection — the Attach routine abnormally 
terminates the caller's task by issuing an 
ABEND macro instruction with an error code 
of "42A". The ABEND macro instruction 
causes, via an SVC interruption, linkage to 
the ABEND SVC routine to abnormally termin- 
ate the task. 

The Attach routine next determines the 
limit and dispatching priorities from input 
parameters and stores the priorities in the 
new TCB. The limit priority of the subtask 
is set according to the input parameter but 
not higher than the limit priority of the 
caller's task. The dispatching priority of 
the subtask is similarly set according to 
the input parameter but not higher than its 
own limit priority. If the priority param- 
eters have not been specified by the call- 
er, the Attach routine sets the subtask 
priorities equal to the limit and dispatch- 
ing priorities of the caller's task. If 
the ATTACH macro instruction was issued by 
a time sharing task, the real limit and 
dispatching priorities and the time sharing 
limit and dispatching priorities are propa- 
gated to their respective fields in the 
subtask TCB. The time sharing priorities 



will be adjusted by the input parameters, 
if any, before the resulting values are 
stored in the subtask TCB. 

If the ROLL parameter is ROLI.= (NO,X) , 
the Attach routine initializes to '01' the 
TCBNROC field. This marks the job step not 
eligible to be rolled out. If, however, 
the parameter is ROLL= (YES,X) , the Attach 
routine initializes the TCBNROC field to 
'00*. This marks the job step eligible to 
be rolled out. (The TCBNROC field is later 
altered by the ENQ and DEQ routines to make 
the job step ineligible to be rolled out 
while one of its tasks is enqueued for a 
system resource.) If the parameter is 
ROLL=(X,yES) , the Attach routine sets the 
TCBFRA flag in the new TCB to indicate that 
the job step is able to cause rollout. If, 
however, the parameter is ROLL=(X,NO), the 
TCBFRA flag is cleared to indicate that the 
job step cannot cause rollout. If the ROLL 
parameter is not specified, both the 
TCBNROC field and the TCBFRA flag are 
cleared to indicate that the new job step 
can be rolled out but cannot cause rollout. 
(The TCBFRA flag is later tested by the 
GETMAIN routine, if the new job step 
requests more storage space than can be 
allocated from its region and if the roll- 
out feature is in the system. The TCBNROC 
field is later tested by the rollout/rollin 
module, during an attempted rollout, to 
determine if the new job step is eligible 
to be rolled out.) 

Programs operating with a PSW protect 
key of zero may specify whether the job 
step pointer is to be propagated and wheth- 
er the job pack queue is to be given to the 
subtask. The Attach routine tests the 
input parameters to determine the follow- 
ing: if the TCBJSTCB pointer should be 
copied from the task's TCB or made to point 
to the attached TCB; if the TCBJSCB field 
should be copied from the requesting task's 
TCB or made to point to a new JSCB whose 
address is given as input; and if the job 
pack queue is to be given to the subtask. 

If the program operating with a PSW pro- 
tect key of zero requests that the job pack 
queue be given to the subtask, the job pack 
queue cannot contain CDEs with use counts 
greater than zero — for these represent 
active programs. If such CDEs are found, 
the Attach routine abnormally terminates 
the caller' s task by issuing an ABEND macro 
instruction with a "32A" error code. 
Otherwise, the TCBJPQ field is copied from 
the attaching task's TCB to the attached 
task's TCB, and then zeroed in the attach- 
ing task's TCB. Also, the chain of SPQEs 
on the attaching task's TCB is searched for 
subpools 251 and 252. If an SPQE is found 
for either or both of these subpools, it is 
dequeued from the attaching task's TCB and 
queued on the attached task's TCB. 
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Special Processing for Time Slicing 

When the time-slicing feature is 
included in the system, the ATTACH routine 
tests whether the new TCB represents a 
time-sliced task. ATTACH locates the first 
time-slice control element (TSCE) through a 
pointer in the CVT, then compares the dis- 
patching priority of the new task with that 
of each TSCE until a match is found or the 
last TSCE is checked. If no match is 
found, the new task is not a member of a 
time-sliced group and further time-slice 
processing is bypassed. 

If a match is found, the new task is a 
member of a time-sliced group. The ATTACH 
routine sets the time- slice bit (TCBFTS) in 
the TCB and updates the TSCE pointers in 
the matched TSCE. If the new TCB repre- 
sents the only task in the group, its 
address will be placed in the "First", 
"Last", and "Next to be Dispatched" fields 
of the TSCE. If the new task is not the 
only one in the group, its TCB is lowest 
onthe TCB queue; the ATTACH routine places 
the address of the TCB in the Last field of 
the TSCE. 

Allocating Subpools of Main Storage 
to the Subtask 

The Attach routine allocates subpools of 
main storage to the attached TCB's programs 
according to parameters passed in the 
supervisor parameter list. These parame- 
ters were specified in the ATTACH macro 
instruction. The " give" parameter causes 
the allocation of specified subpools of 
main storage to the programs of the 
attached subtask for their exclusive use. 
The "share" parameter permits the programs 
of the subtask and the programs of the 
parent task to share access to the same 
subpools of main storage. The Attach rou- 
tine manipulates ownership of the subpools 
by manipulating special Main Storage Super- 
visor queue elements, each representing a 
subpool of main storage. Each subpool 
queue element, originally queued to the 
parent TCB, may be either dequeued and 
placed on the subtask TCB's subpool queue 
("give" parameter specified), or placed on 
the subtask TCB's subpool queue as dupli- 
cate queue elements ("share" parameter 
specified) . 

For each subpool specified in a "give" 
parameter, the Attach routine searches the 
subpool queue belonging to the caller's 
task. The queue starts at the address con- 
tained in the TCBMSS field of the call- 
er's TCB. If a subpool queue element 
(SPQE) for the specified subpool is found 
on the queue, it is dequeued and placed on 
the new subtask' s subpool queue. If the 
subpool queue element is not found, a new 
element for the subpool is created, placed 



on the subpool queue belonging to the sub- 
task, and flagged as an "owned" subpool. 

For each subpool specified in a "share" 
parameter, the Attach routine similarly 
searches the subpool queue chained from the 
parent, or caller's, TCB. In this case, 
however, if the subpool queue element is 
found, a new subpool queue element for the 
same subpool is created and placed on the 
subtask' s subpool queue. The elements 
representing the same subpool (that is, the 
original queue element and its duplicate) 
are both flagged as "shared" subpools. But 
if an original subpool queue element is not 
found on the parent task's subpool queue, 
two queue elements are created. One is 
flagged "owned" and "shared" and is queued 
to the parent task's subpool queue. The 
other element is flagged "shared" and is 
queued to the subtask' s subpool queue. 

There are two errors associated with the 
allocation of main storage to an attached 
subtask. Either error, when detected, 
causes the Attach routine to abnormally 
terminate the caller's task by issuing an 
ABEND macro instruction and specifying an 
error code. One error consists of the spe- 
cification of the "give" or "share" parame- 
ter with a subpool number greater than 127, 
the maximum number for a subpool belonging 
to a user program. Such an error produces 
an abnormal termination of the caller's 
task and an error code of 22A. The other 
error occurs if the "give" parameter speci- 
fies a subpool whose queue element, when 
found, contains both the "owned" and 
"shared" attributes. In this case, the 
subpool cannot be "given" to the subtask. 
The resulting abnormal termination of the 
caller's task includes the error code 12A. 

A special subpool of main storage, sub- 
pool zero, is processed separately. If 
subpool zero is specified with the "give" 
or "share" parameters, the specification is 
ignored. 

The Attach routine tests the SZERO pa- 
rameter to determine whether subpool zero 
is to be shared. If not, the Attach rou- 
tine has completed main storage allocation 
for the subtask and proceeds to its next 
function. However, if subpool zero is to 
be shared, the Attach routine searches the 
subpool queue of the parent task and 
creates the needed subpool queue elements, 
which are then chained from the parent and/ 
or subtask TCB. 

Placing the Subtask TCB on Its Queues 

The new TCB for the attached subtask is 
placed by the Attach routine on two TCB 
queues: the subtask queue for the parent 
TCB, and the main TCB queue. The subtask 
queue indicates the order in which TCBs 
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were created, and is used by the supervisor 
ABEND routine during abnormal termination 
to establish the order in which a job 
step's resources are freed. The main TCB 
queue, or simply the TCB queue, is the 
queue of TCBs arranged in order of priori- 
ty. This queue is manipulated by the CHAP 
SVC routine when it changes the dispatching 
priority of a TCB. The TCB queue is also 
used by the supervisor's Dispatcher routine 
when it tests which program should next be 
dispatched. The Dispatcher sometimes scans 
down this queue to determine the highest 
priority ready TCB. Both queues, the sub- 
task queue for the parent TCB, and the TCB 
queue, consist of the same physical TCBs. 
The queues are created and manipulated by 
means of different sets of pointers within 
each TCB. (Refer to Section 12, "Control 
Blocks and Tables," to note the meaning of 
each pointer within the TCB) . 



Preparation for the Dispatching of the 
Caller and the Fetching' of the Specified 
Program 

To prepare for return of control to the 
caller, the Attach routine moves the call- 
er's register contents, saved in the SVRB 
by the SVC Second-Level Interruption Han- 
dler, to the save area of the caller's TCB. 
It also stores the address of the new sub- 
task TCB in the register 1 save area loca- 
tion (TCBGRS) in the caller's TCB. These 
values will be loaded into the general 
registers by the Dispatcher when it next 
returns control to the caller, or attaching 
program. When the attaching program is 
redispatched, it regains control at the 
instruction immediately after the ATTACH 
macro instruction. The address of the new 
subtask TCB in register 1 is the return pa- 
rameter from the Attach routine. 



If the ATTACH macro instruction was 
issued by a time sharing task, the new sub- 
task TCB is placed on the queue using the 
time sharing dispatching priority. The 
Attach routine uses the time sharing job 
block extension (TJBX) to locate the user' s 
subgroup on the queue. The Attach routine 
also determines whether there are enough 
entries in the quiesce parameter list for 
all active TCBs. If not, the current QPL 
is freed and a GETMAIN macro instruction is 
issued to obtain area for a new QPL that is 
twice as large as the QPL that was freed. 



Indicating to the Dispatcher the Need for a 
Task Switch 

The Attach routine passes control to the 
Task Switch routine to determine if the 
parent TCB's current program or the subtask 
TCB's current program will receive control 
when the Dispatcher gives control to a main 
line program. The Task Switch routine 
examines the dispatching priorities of the 
two TCBs, parent and subtask, and stores 
the address of the higher priority TCB in a 
"new" TCB pointer (lEATCBP) to be later 
tested by the Dispatcher, when it receives 
control during the exiting procedure. 



In a Model 65 Multiprocessing System, 
the parent and subtask TCBs may both have 
higher dispatching priorities than the cur- 
rent TCB on one CPU, so the Task Switching 
routine examines the dispatching priorities 
of three TCBs: the subtask TCB and the two 
"new" TCBs. If the "hew" TCB pointer of 
either CPU contains zero, the Task Switch 
routine sets the "new" pointer of the CPU 
on which the task switch must be made to 
zero so the Dispatcher will search the TCB 
queue to determine the highest priority 
tasks. 



In order to obtain execution of the pro- 
gram specified in the ATTACH macro instiruc- 
tion, the Attach routine must obtain the 
assistance of one of the functions of con- 
tents supervision, called the Link func- 
tion. The Link function will locate the 
desired program in main storage or in one 
of the auxiliary storage libraries, fetch 
the program to main storage, and cause 
linkage to the program for the newly 
created subtask. 



The Attach routine determines the input 
register values for Contents Supervision 
and stores them in the new TCB. It also 
moves the entry point parameter — either 
an entry point name or a partitioned data 
set directory entry — from the input pa- 
rameter list to the SVRB. The purpose is 
to prepare the SVRB for the control of Con- 
tents Supervision when it has been dis- 
patched under the control of the new TCB. 
Another purpose of moving the entry point 
parameter is to peinnit the attaching pro- 
gram to reuse the parameter-list area if 
the program is redispatched before the Link 
function is complete. 

The Attach routine dequeues its SVRB 
from the caller's TCB and queues it as the 
current RB for the new subtask. If a save 
area is not to be provided for the subtask, 
the Attach routine alters the old PSW in 
the SVRB so that it points to the special 
entry point in the Link function 
(lEAQCSOl) . The Link function is thus made 
the first routine to be executed for the 
newly created subtask when it becomes 
active. If a save area is to be provided 
for the subtask, the Attach routine alters 
the old PSW in the SVRB so that it points 
to a return point in the Attach routine 
where a save area is obtained when the 
newly created subtask becomes active. 
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By manipulating the register save areas, 
the Attach routine has established environ- 
ments for the two TCBs. Also, the TCB and 
RB queues have been modified so that both 
TCBs are ready to be dispatched. The 
Attach routine branches directly to the 
Dispatcher to give control to the current 
routine of the higher priority of the two 
tasks, the attaching task or its newly 
created subtask. Note that the Attach rou- 
tine branches directly to the Dispatcher, 
without the typical intermediate step of 
the supervisor Exit routine. The reason is 
that the Attach routine has already per- 
formed or made unnecessary the functions 
which the supervisor Exit routine normally 
performs. For example, the Exit routine 
normally removes the current RB from the 
TCB of the exiting program. Since the 
Attach routine has already removed its SVRB 
from the caller's TCB, it cannot branch to 
the Exit routine. 

When a save area is to be provided, the 
Attach routine goes to the Dispatcher only 
once; that is, before the subtask 's Attach 
routine gets the save area. Then, instead 
of delaying the task by going to the Dis- 
patcher again, the Attach routine branches 
directly to the special entry point in the 
Link function (lEAQCSOl) . 



CHANGING THE PRIORITY OF A TASK 

The CHAP SVC routine permits a problem 
or system program to alter the dispatching 
priority of its own TCB or the dispatching 
priority of one of its subtask TCBs. The 
subtask TCB must belong to the issuer's 
TCB; that is, be attached by a routine 
belonging to the caller's task, and there- 
fore reside on its subtask queue. A pro- 
gram issuing the CHAP macro instruction may 
change the dispatching priority of a speci- 
fied TCB to any value between zero and the 
limit priority of the issuer's TCB. The 
distinction between dispatching and limit 
priorities is as follows. Although both 
priorities are specified as parameters of 
the ATTACH macro instruction, they serve 
different functions. The dispatching 
priority determines the appropriate posi- 
tion of a TCB in the TCB queue, and 
indirectly the routine to be next placed in 
execution after an interruption. The Dis- 
patcher places in execution the current 
program belonging to the ready TCB of high- 
est dispatching priority. In contrast, the 
limit priority of a TCB is used by the CHAP 
SVC routine to determine the maximum value 
to which it may increase the dispatching 
priority of the TCB. 

The CHAP routine can receive control as 
a type-1 SVC routine from the SVC FLIH, or 
serve as a subroutine via a branch entry 
from a supervisor routine. If it receives 



control through the branch entry , or if the 
caller is a system routine (protection 
key=0) , the CHAP routine bypasses the usual 
validity checking of the input parameters. 
The assumption in this case is that the 
input parameters are valid and will not 
cause a program check when they are used by 
the CHAP routine. 

After the CHAP routine has determined 
the type of requestor, it checks the input 
parameter for zero. If it is zero, the 
caller's TCB is the TCB whose dispatching 
priority is to be changed, and there is no 
parameter whose validity need be checked. 
But if the input parameter is not zero, it 
is the address of a word in main storage 
pointing to the TCB vdiose priority should 
be changed. In this case, the CHAP routine 
branches to a validity check subroutine 
used by many SVC routines to test an input 
parameter. The test determines if the 
parameter is a valid address and does not 
violate storage protection. If the address 
is not valid, the CHAP routine sets up an 
error code (220 , and branches to the 
ABTERM routine of the supervisor to sched- 
ule the abnormal termination of the call- 
er's task. But if the address is valid, 
the CHAP routine determines if the speci- 
fied TCB is a valid subtask TCB of the cal- 
ler's task. It does this by searching the 
subtask queue of the caller's task, looking 
for the TCB address pointed to by the input 
parameter. The search is for a match 
between the address of the specified TCB 
and the address of one of the subtask TCBs. 
If the search does not produce a match, the 
assumption is that the input TCB was incor- 
rectly specified. The CHAP routine in this 
case branches to the ABTERM routine with an 
error code (12C) to schedule an abnormal 
termination of the caller's task, since the 
requested service cannot be provided. But 
if the address of the specified TCB matches 
that of one of the TCBs on the subtask 
queue, or represents the issuer's TCB, and 
the subtask has not been terminated, vali- 
dity checking is complete and normal pro- 
cessing continues. 

If the time-slicing feature is included 
in the system, the CHAP routine tests 
whether the specified TCB represents a 
time-sliced task. CHAP does this by test- 
ing the time-slice bit (TCBFTS) in the TCB. 
If the bit is set, the task is time-sliced; 
the CHAP routine then resets the bit, and 
finds the time-slice control element (TSCE) 
that corresponds to the task's dispatching 
priority. If the address of the TCB is not 
the same as the First, Last, or Next fields 
in the TSCE, the new dispatching priority 
is determined; no change is required in the 
TSCE. (See Figure 3-3 for TSCE pointers.) 
If the address of the specified TCB appears 
as one of the above fields, the CHAP rou- 
tine modifies the pointers as follows: 
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Field Containing 
TCB Address 
First, Last, 
and Next 



First but not 
Last 



Last and Next 
(not First) 



Last but not 
Next 



Meaning and CHAP 

Processing 

Specified task is the 

only one in the group. 

CHAP sets all fields to 

zero to indicate the 

group is now empty. 

Specified task is not 
the only one in the 
group. CHAP places 
address of next lower 
task on TCB queue into 
First. 

Specified task is last 
in group and next to be 
dispatched. CHAP places 
address from First into 
Next and address of next 
higher TCB on TCB queue 
into Last. 

CHAP places address of 
next higher TCB on TCB 
queue into Last. 



If the issuer is a time sharing task, 
the time sharing dispatching and limit 
priorities in the TCBs are used instead of 
the real dispatching and limit priorities. 
Only tasks within a user's subgroup, as 
defined by the time sharing job block 

TCB QUEUE 



TSCE 



FIRST 



LAST 



NEXT 



Length of 
Time-Slice 



TSCE pointers after first 
time-sliced task has completed 
its time-slice interval. 



TIME-SLICE I 
GROUP |_ . 



.J 



Figure 3-3. 



TSCE Pointers 



extension, can be affected by CHAP. The 
changed TCB is placed on the TCB queue 
immediately preceding the TCB with the next 
lower dispatching priority. 

The remainder of the CHAP routine con- 
tains several tests to determine the extent 
of the priority change that can be per- 
mitted. The first test checks whether the 
result of the change in dispatching priori- 
ty is zero or negative. In either case the 
CHAP routine sets the dispatching priority 
field (TCBDSP) of the specified TCB to 
zero. (A negative dispatching priority is 
meaningless and is treated as a request for 
a change to zero priority. ) 

The remaining tests will be discussed as 
separate cases, as follows: 

Case 1 ; The result of the requested change 
would be a dispatching priority greater 
than zero, but equal to or less than the 
TCB. The CHAP routine algebraically adds 
the desired change to the original dis- 
patching priority of the specified TCB and 
places the result in the dispatching 
priority field CTCBDSP) of the TCB. The 
request is thus satisfied. 

Note ; The remaining cases consider condi- 
tions in which the result of the change is 
greater than the limit priority (TCBLMP) of 
the specified TCB. 

Case 2 ; The specified TCB represents a 
subtask of the issuer's TCB, and the 
desired change would make the dispatching 
priority of the subtask TCB greater than 
the limit priority of its parent (issuer's) 
TCB. In this case, the CHAP routine cannot 
quite satisfy the request. It sets both 
the dispatching priority (TCBDSP) and the 
limit priority (TCBLMP) of the specified 
TCB equal to the limit priority of the 
parent TCB. The request is thus satisfied 
within the limits of the system. 

Case 3 ; The specified TCB represents a 
subtask of the issuer's TCB, and the 
desired change would not make the dispatch- 
ing priority of the subtask TCB greater 
than the limit priority of its parent TCB. 
In this case the CHAP routine sets both the 
dispatching priority and limit priority of 
the specified TCB to the value produced by 
the change. This time the request can be 
completely satisfied without any compro- 
mises. 

Case 4 ; The specified TCB is the issuer's 
TCB. In this case, since the result of the 
desired change would be a dispatching 
priority that exceeds the limit priority of 
the issuer's TCB, the request cannot be 
completely satisfied. The CHAP routine 
sets the dispatching priority of the 
issuer's TCB equal to its limit priority. 
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If the time-slicing feature is included 
in the system, the CHAP routine tests 
whether the new dispatching priority is 
time-sliced. If there is a TSCE for the 
priority, the CHAP routine sets the time- 
slice bit (TCBFTS) in the TCB. The CHAP 
routine tests the Next field in the TSCE; 
if it contains zero, the specified task is 
the only member of the time-sliced group, 
and the CHAP routine places its TCB address 
in the First, Next, and Last fields in the 
TSCE. Otherwise, the new TCB address is 
stored in the last field. 

Having changed the dispatching priority 
of the TCB, the CHAP routine must next 
realign the TCB queue so that it is ordered 
from high to low dispatching priority. 
This queue is sometimes used by the Dis- 
patcher during the exiting procedure to 
determine the highest priority ready task 
whose current routine it should dispatch. 

In order to reorder the TCB queue, the 
CHAP routine searches the TCB queue for two 
TCBs. One is the specified TCB whose dis- 
patching priority it has just changed; the 
other is the first TCB that has a lower 
dispatching priority than the new priority 
of the specified TCB. The CHAP routine 
begins its search at the highest priority 
TCB, located at address lEAHEAD. (See 
Figure 3-t.) The address lEAHEAD is con- 
tained in a field (CVTHEAD) of the communi- 
cations vector table. This table, also 
called the CVT, contains pointers to major 
control blocks used by the control program. 

Note on Figure 3-4 that the pointer 
(TCBTCB) in each TCB points to the next 
lower priority TCB on the queue. (Refer to 
the TCB description in Section 12, "Control 
Blocks and Tables , " for the positions of 
the permanent system TCBs on the TCB 
queue. ) 

When the CHAP routine finds the two TCBs 
(the specified TCB and the next lower 
priority TCB) it rearranges pointers so 
that the specified TCB is removed from its 
current position on the queue and rein- 
serted just above the next lower priority 
TCB. If other TCBs on the queue have a 
priority equal to the new dispatching 
priority of the specified TCB, it is placed 
below them on the queue. 



During its search of the TCB queue, the 
CHAP routine branches to the Task Switching 
routine to determine if there is a ready 
TCB whose dispatching priority is now high- 
er than that of the caller's TCB. This 
situation can occur in two different ways. 
The caller may have changed one of its sub- 
tasks to a priority higher than that of its 
own tasks, or the caller may have changed 
its own tasks to a lower priority. When 



Location CVTHEAD 
in CommunicaHons 
Vector Table 



TCB A (Addr lEAHEAD) 



Pointer to 
Addr lEAHEAD 



TCBTCB 



DP= 10 



TCB C 



TCBTCB 



DP ^ 



TCB D 



TCBTCB 



DP = 2 



TCBE 






TCBTCB 
(Contains 


Zero) 


DP= 1 



TCB B 



TCBTCB 



DP = 8 



Legend : DP - dispatching priority value 

Note : Each TCBTCB field points to the TCB of next lower dispatching priority. 

Figure 3-t. The Task Control Block Queue 



the TCB queue is reordered, a TCB previous- 
ly of lower priority than the caller's now 
exceeds the caller's priority. In a multi- 
processing system, there also may be a 
ready TCB whose dispatching priority is 
higher than that of the current task on the 
second CPU. 

If the Task Switching routine finds a 
ready TCB with a higher dispatching priori- 
ty, it indicates to the Dispatcher the need 
for a task switch. The indication, also 
performed by other supervisor routines, 
consists of storing the address of the 
higher priority TCB in a one-word "new" TCB 
pointer at address lEATCBP. During the 
exiting procedure that follows the execu- 
tion of an SVC routine, the Dispatcher 
inspects the "new" TCB pointer to determine 
if it should redispatch the interrupted 
routine or the current routine belonging to 
another ready task. 

After the CHAP routine has realigned the 
position of the specified TCB in the TCB 
queue, it returns control either to the 
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caller or the current routine of another 
ready task. If the CHAP routine was 
entered via a branch from a supervisor rou- 
tine, it returns control directly to the 
caller, deferring any indicated task switch 
to the next time the Dispatcher is entered. 
But if the CHAP routine was entered from 
the SVC FLIH, via an SVC interruption, it 
branches to the Type-1 Exit routine. The 
Type-1 Exit routine tests whether the CHAP 
routine has indicated the need for a task 
switch. If it has, the Type-1 Exit routine 
branches to the Dispatcher to give control 
to the current routine of the higher 
priority task. But if the need for a task 
switch has not been indicated, the Type-1 
Exit routine returns control directly to 
the caller. 



EXTRACTING INFORMATION FROM A TASK CONTROL 
BLOCK 

The purpose of the Extract SVC routine 
is to permit the macro-issuing or calling 
program to obtain from a specified TCB or a 
subsidiary control block the information 
contained in eleven of its fields. The 
specified TCB must be either the TCB of the 
issuing program or of one of its subtasks 
— tasks attached by the issuing progreun. 
The information may be extracted from any 
combination of the eleven fields or from 
all of the eleven fields. When extracted, 
the information is placed in a user- 
specified list. The fields from which 
information may be extracted and the infor- 
mation contained in each field are 
described in the Supervisor Services and 
Macro Instructions , under the heading of 
"Extract. " 

Besides extracting information from a 
specified TCB or a subsidiary control 
block, the Extract routine perfoinns several 
checks to determine if the input parameters 
passed by a problem program are valid. 
This validity checking prevents the extrac- 
tion of meaningless data, or the later 
occurrence of a program interruption whose 
cause may be difficult to interpret. Input 
parameters, if incorrectly specified by the 
using program, cause the routine to gener- 
ate an error code and cause an abnormal 
termination of the offending task. 



Like certain other type-1 SVC routines, 
the Extract routine may be entered either 
from the SVC FLIH during an SVC interrup- 
tion, or via a branch from a Supervisor 
routine. The routine first tests the type 
of entry and sets indicators accordingly. 
It also determines whether information is 
to be extracted from the current TCB (call- 
er's TCB) or from the TCB of one of its 
subtasks. If information is to be 
extracted from the current TCB, its address 



is set up, and the following test and pre- 
cautionary measure for a subtask is 
bypassed. 



If the specified TCB represents a sub- 
task of the caller's TCB, the Extract rou- 
tine prevents a possible program interrup- 
tion by forcing the TCB pointer C second 
word of the input parameter list) to a ful- 
Iword boundary. The routine then scans the 
subtask queue of the caller's TCB. Its 
purpose is to determine if the specified 
TCB address truly represents a subtask of 
the caller's TCB. If no match of TCB 
addresses can be obtained, the caller must 
have incorrectly specified the TCB address- 
Since useful information cannot be obtained 
from the specified TCB, the Extract routine 
schedules an abnormal termination similar 
to that previously discussed. An error 
code (328) defining the incorrect address 
specification is passed to the ABTERM 
routine - 

The Extract routine next determines 
whether it should check the validity of the 
input parameters supplied by the calling 
program. If the caller is a system rou- 
tine, as indicated by a protection key of 
zero in the SVC old PSW, the assumption is 
that the caller has checked its parameters 
before passing them to the Extract routine. 
In this case no linkage to the Validity 
Check routine occurs, and the Extract rou- 
tine immediately obtains the desired infor- 
mation. The Validity Check routine is used 
by SVC routines to check the validity of 
input parameters passed to the routines by 
a user program. If the caller is not a 
system routine, its input parameters must 
be checked. Accordingly, the Extract rou- 
tine passes control to the supervisor's Va- 
lidity Check routine to perform the needed 
checking. 

The Validity Check routine performs 
three tests to determine the correctness of 
the extract list address- The extract list 
is the user-specified table in which the 
Extract routine places the requested TCB 
information. One test determines if the 
list address lies on a fullword boundary, 
as required. Another test checks whether 
the list address lies within the boundaries 
of main storage. The remaining test deter- 
mines if the list address specifies a 
storage area whose storage protection key 
matches the protection key in the caller's 
TCB. If any of these tests fail, indica- 
ting that the calling program has incor- 
rectly specified the extract list address, 
the Extract routine branches to the ABTERM 
routine, passing to it an error code (128) 
indicating the type of incorrect specifica- 
tion. The ABTERM routine will schedule 
linkage to the ABEND routine, which will 
abnormally terminate the caller's task. 
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The validity checking detects an inva±ia 
list address that could cause a program 
check if it were used by the Extract rou- 
tine. More important, the validity check- 
ing detects whether the caller has passed a 
list address pointing to a storage area 
which is not owned by the caller. There- 
fore, Extract can avoid storing into loca- 
tions specified by the list. If the 
Extract routine used the list address 
without validity checking, it could store 
anywhere in storage, destroying data or 
programs belonging to another job step or 
to the supervisor. It could do this, since 
it operates with a storage protection key 
of zero. Note that validity checking does 
not prevent the caller from passing an 
invalid list address which causes the 
Extract routine to destroy the caller's 
data or program or the data or programs of 
another task in the caller's job step. 

If input parameters have been specified 
correctly, as indicated by the several va- 
lidity checks, or if validity checks have 
been bypassed, normal processing of the 
requested TCB information continues. The 
Extract routine tests each bit of an 
extraction byte, a part of the parameter 
list, which represents the FIELDS parameter 
of the EXTRACT macro instruction (see 
"Extract" in Supervisor Services and Macro 
Instructions ) . For each bit that is set, 
the Extract routine places the appropriate 
information from the specified TCB into the 
user list. If a bit is not set, the rou- 
tine makes no entry in the list for the 
field represented by that bit. The result- 
ing list is of variable length and packed 
in a standard order. 

Note that some of the fields that may be 
requested are not directly contained in the 
specified TCB. These fields are those 
requested by the following parameters: GRS 
(general register save area) , FRS 
(floating-point register save area) , the 
AETX (end-of-task exit routine), and COMM 
(CSCB communications list) , PSB (protected 
storage control block) , and the TJID (TSO 
terminal job identifier) . For the first 
two parameters the returned value is the 
address of the appropriate save area. The 
value is calculated from the address of the 
specified TCB. The returned value points 
to the save areas which are in the TCB. 
For the third parameter, AETX, the returned 
value (address of the exit routine) is 
obtained indirectly from the TCB. The 
TCBIQE field in the TCB points indirectly 
to the end-of-task exit routine, via poin- 
ters in two other control blocks, an inter- 
ruption queue element (IQE) and an inter- 
ruption request block (IRB) . The address 
of the end-of-task exit routine is obtained 
from the IRB. (See Figure 3-1.) For the 
next two parameters, the returned values 
(addresses of the communications list and 



me protected storage control block) are 
also obtained indirectly. The TCB points 
to the JSCB, which contains the address of 
the CSCB communications list and the PSB. 
The TJID field contains the TSO terminal 
job identifier value. 



When the Extract routine has placed all 
the requested information in the user- 
specified list, it either returns control 
directly to the caller, or prepares for a 
return to a program by branching to the 
Type-1 Exit routine. The Type-1 Exit rou- 
tine, after making certain tests, will 
either return control directly to the call- 
er, or branch to the Dispatcher to return 
control to the current routine belonging to 
another TCB. If, however, entry to the 
Extract routine occurred from a supervisor 
routine via a branch, the Extract routine 
returns control directly to the caller. 



DETACHING A SUBTASK 

The Detach SVC routine permits a program 
being executed for a "parent" task to 
detach its subtask if the subtask has been 
normally or abnormally terminated. The 
Detach routine checks that the address of 
the subtask' s TCB passed to the Detach rou- 
tine is valid, and that the subtask has 
been terminated. It dequeues the subtask 
TCB from the subtask queue of its parent 
TCB and frees storage areas belonging to 
the subtask, including the svibtask TCB 
itself. If the caller specifies an invalid 
subtask TCB address, the Detach routine 
abnormally terminates the caller's task. 
But, if the subtask has not been normally 
or abnormally terminated previously, it is 
now abnormally terminated. 

The Detach routine is entered from the 
SVC SLIH. To determine if the caller has 
passed a valid TCB pointer, the Detach rou- 
tine first branches to the supervisor's Va- 
lidity Check routine to test the supposed 
subtask TCB address. The Validity Check 
routine does not determine if the address 
belongs to a TCB but only that it will not 
later cause a program check. If any valid- 
ity check fails, the check routine informs 
the Detach routine by supplying a return 
code. In this case, the Detach routine 
sets up an error code (0023E000) and issues 
an ABEND macro instruction to obtain super- 
visor linkage to the ABEND routine to 
abnormally terminate the caller's task. If 
the input address is valid, the Detach rou- 
tine proceeds as follows. 

The routine next determines if the call- 
er belongs to the parent task of the speci- 
fied subtask. It does this by searching 
the subtask queue of the caller's TCB for 
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the specified TCB address. The list origin 
for the parent task's subtask queue is the 
TCBLTC field of the parent's TCB. If the 
subtask TCB address is not found, ^ the 
Detach routine sets up the same error code 
{0023E000) as that for an invalid TCB 
address, and obtains linkage, via an ABEND 
macro instruction, to the ABEND routine to 
abnormally terminate the caller' s task. 
But if the specified subtask TCB address is 
found in the subtask queue, processing 
continues . 

The Detach routine next determines if 
the subtask is complete, that is, whether 
the task has been terminated by either the 
EOT routine or the ABEND routine. The 
Detach routine makes this determination by 
testing the "completion" indicator TCBFC in 
the TCBFLGS field of the subtask TCB. This 
indicator bit is set by the EOT routine or 
by the ABEND routine. If the subtask has 
not terminated, normally or abnormally, 
detaching cannot occur. In this case, the 
Detach routine performs processing to 
abnormally terminate the subtask. (This 
processing will be described later in this 
discussion. ) But if the subtask has been 
terminated, normally or abnormally, the 
Detach routine proceeds with its process- 
ing, as follows. 

Since the subtask is terminated, the 
routine must remove the subtask TCB from 
the subtask queue of the caller's TCB. 
This is necessary since the ABEND or EOT 
routines during a later termination of the 
caller's task will try to release resources 
supposedly belonging to its subtasks. 

After removing the subtask TCB from its 
subtask queue, the Detach routine frees 
storage areas belonging to the subtask that 
were not freed during the termination pro- 
cess. These storage areas include a 
problem- program register save area, if the 
subtask has such an area, and the space 
occupied by the subtask' s TCB. The save 
area consists of 72 bytes in subpool 250; 
the TCB contains 192 bytes in subpool 253, 
supervisor queue space. If the subtask has 
a problem-program register save area, its 
address is contained in the TCBFSA field of 
its TCB. After freeing the subtask' s 
storage areas for reuse, the Detach routine 
returns control to the caller- 

If the specified subtask has not com- 
pleted processing, Detach determines if the 
requester has specified STAE=YES as an 



^The subtask TCB is not found if neither an 
ECB nor an ETXR was specified when the 
subtask was attached, and the subtask has 
been terminated, normally or abnoirmally. 
In this case, the subtask TCB has been 
purged. 



operand of the DETACH macro instruction. 
This will allow the STAE exit routine to be 
entered during subsequent ABEND processing. 
If STAE=YES was specified and the subtask 
is not already being terminated by ABEND, 
Detach determines if an IQE is pointed to 
by the subtask TCB. If so, the IQE is 
freed and, if the use count in the IRB is 
not greater than 1, the IRB is also freed. 
If the use count is greater than 1, it is 
decremented but the IRB is not freed. For 
all cases where STAE=YES and the subtask is 
not being teinninated by ABEND, Detach loads 
the error code 0033E000, resets the stop/ 
start nondispatchability flag, and, if no 
secondary nondispatchability flags are set, 
clears the primary nondispatchability flag. 
Detach branches to ABTERM to schedule ab- 
normal termination of the subtask and then 
returns control to the caller. 

If the requester had specified STAE=NO, 
or if STAE=YES was specified but the sub- 
task is already being terminated by ABEND, 
Detach loads the error code 0013E000. If 
the subtask is not being terminated by 
ABEND, Detach resets the stop/start nondis- 
patchability flag and branches to ABTERM to 
schedule abnormal termination of the 
subtask. 

The Detach routine next saves in its 
SVRB the address of the subtask' s event 
control block (ECB), if one was specified 
when the subtask was attached. (The ECB 
address is contained in the subtask' s 
TCBECB field. ) The Detach routine then 
obtains four bytes of space (subpool 250) 
for a new ECB in which the ABEND routine^ 
can post the subtask 's termination. The 
Detach routine initializes the new ECB to 
zero and places its address in the subtask 
TCB (TCBECB field) . The routine also 
clears the IQE pointer (TCBIQE) in the sub- 
task TCB, so that an end-of-task exit rou- 
tine (if one exists) will not be scheduled 
by the EOT routine when the subtask is ter- 
minated. (The TCBIQE field contains an 
indirect pointer to an end-of-task exit 
routine (ETXR) , if the caller specified the 
ETXR operand when it attached the subtask.) 

The Detach routine then waits (issues a 
WAIT macro instruction) for the ABEND rou- 
tine to complete the abnormal termination 
of the subtask. The abnormal termination 
of the subtask is signaled by the release 
of the Detach routine from its wait condi- 
tion via the posting of the new ECB by the 
EOT routine. The Detach routine then frees 
the storage occupied by the special ECB it 
had created and tests whether the subtask 
has its own ECB. (The Detach routine saved 



^The actual posting is performed for the 
EOT routine, which is invoked by the ABEND 
routine when the termination is complete. 
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the subtask's ECB address — if it had an 
ECB — in the current SVRB.) 

If the subtask does not have an ECB 
which the Detach routine can post to inform 
the caller of the subtask termination, the 
Detach routine resumes normal processing by 
removing the subtask TCB from the subtask 
queue originating in the TCB of the requ- 
esting task. 

If, however, the subtask has an ECB, 
Detach branches to the entry point in the 
Post routine that provides validity check- 
ing for the ECB, and, if the ECB is valid, 
posts the ECB. Upon return from the Post 
routine. Detach resumes processing by 
removing the subtask TCB from the subtask 
queue. 



SERVICES INDIRECTLY RELATED TO A TASK 
CONTROL BLOCK 

These varied services consist of; 

• Specifying a program interruption exit 
routine- 

• Sychronizing a program with one or more 
events . 

• Serializing the use of a resource. 

• Scheduling an asynchronous exit 
routine. 

• Specifying a task asynchronous exit 
routine . 

A user program may specify a program 
interruption exit routine which will handle 
program interruptions occurring during any 
program executed for the user's task. The 
supervisor must be able to test for the 
existence of a user routine. The SPIE rou- 
tine therefore places in the TCB of the 
macro-issuing program an indirect pointer 
to the user routine. If after a program 
interruption has occurred, the Program 
Interruption First-Level Interruption Han- 
dler finds an address in the pointer field, 
it passes control to the user routine to 
handle the interruption. Otherwise, the 
FLIH uses the ABTERM routine to schedule an 
abnormal termination of the task whose 
error caused the interruption. 

By use of the Wait and Post routines, a 
user or system program may synchronize its 
execution with the occurrence of one or 
more events, such as the completion of an 
I/O operation. The Wait routine stops the 
execution of the requester until the speci- 
fied events have occurred. When they have 
occurred, the Post routine indicates their 
occurrence by altering bits in one or more 
event control blocks. It then makes ready 



the waiting requester so that it may be 
placed into execution by the Dispatcher. 

By serializing the use of resources, the 
ENQ and DEQ routines permit requesters 
representing different tasks to gain one- 
at-a-time access to a resource or set of 
resources. The resources may include one 
or more data sets, records within a data 
set, programs, or work areas within main 
storage. If the resource is available, 
control is returned to the requester, 
optionally with a return code indicating 
the availability of the resource. If the 
resource is not available, either of two 
functions are performed, depending on the 
RET parameter that is supplied by the requ- 
ester. The requester is placed in a wait 
condition, pending the availability of the 
resource, or control is returned to the 
requester with a code indicating that the 
resource is not available. When a routine 
has issued a DEQ macro instruction to sig- 
nal that it is no longer using the 
resource, the DEQ routine reduces the wait 
count of a waiting requester and tests it 
for readiness. If the requester is now 
ready, the DEQ routine determines if the 
requester can be executed in place of the 
DEQ-issuing routine. 

An asynchronous exit routine is sched- 
uled by the supervisor to provide special 
handling of an unpredictable event, such as 
an end-of-task condition or the expiration 
of a timer interval. The scheduling of the 
exit routine, begun when the event actually 
occurs, is a multipart procedure interwoven 
with the performance of different tasks. 
Preparation for the event takes place when 
a system routine issues a CIRB macro 
instruction to cause the Exit Effector, 
stage 1, to construct an interruption re- 
quest block or IRB. The IRB will control 
the future execution of the asynchronous 
exit routine when it is scheduled. When 
the unpredictable event occurs, the super- 
visor invokes stage 2 of the Exit Effector 
to begin the scheduling by placing an 
interruption queue element on a push-down 
exit queue. Final scheduling, performed by 
stage 3 of the Exit Effector, moves the 
interruption queue element to a queue 
belonging to the IRB. The IRB is then 
queued to the "head" position on the RB 
queue belonging to the requester's TCB. 
When the TCB to which the IRB is queued is 
the highest priority ready TCB, the Dis- 
patcher places the asynchronous exit rou- 
tine in execution for its assigned task. 
When the asynchronous exit routine is 
finished, the supervisor's Exit routine 
removes the old scheduling and prepares for 
new scheduling. That is, it updates queue 
elements and prepares to queue the IRB to 
the RB queue of another TCB, if there are 
other requests for the exit routine. If 
there are no other requests, the supervi- 
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sor's Exit routine dequeues the IRB from 
its TCB, and if the IRB was dynamically 
acquired, frees the storage space it 
occupies. 

An asynchronous (user) exit routine can 
also be specified to receive control when a 
task is scheduled for ABEND processing; 
however, the processing to handle this exit 
routine is considerably different. The 
STAE macro instruction prepares the task to 
intercept abnormal termination processing 
through the STAE service routine, which 
receives control via an SVC 60 when the 
STAE macro instruction is issued. When the 
task has entered ABEND processing, the 
ABEND/STAE interface routine is invoked, 
which schedules a user-written STAE exit, 
routine via the SYNCH macro instruction. 
If the STAE exit routine indicates that a 
retry routine should be scheduled, the 
ABEND/STAE interface routine sets the 
resume PSW to point to the address of the 
STAE retry routine. The ABEND/STAE inter- 
face routine then exits, giving control to 
the Dispatcher. (See Section 10, "Termina- 
tion Procedures," for a detailed descrip- 
tion of the STAE service routine and the 
ABEND/STAE Interface routines.) 



SPECIFYING A PROGRAM INTERRUPTION EXIT 
ROUTINE 

Before reading the following discussion, 
the reader should carefully study "Program 
Interruption Processing" in Supervisor Ser- 
vices and Macro Instructions . 

The SPIE routine completes the process- 
ing needed for a user to specify a program 
interruption exit routine. The initial 
processing — creating and initializing the 
fields of a program interruption control 
area (PICA) — is perfoimed by executable 
code produced by the expansion of the SPIE 
macro during an assembly of the source pro- 
gram. The execution of the instructions of 
the macro expansion places in the fields of 
the PICA a program mask, the address of the 
user program-interruption exit routine, and 
an interruption mask. If after the execu- 
tion of the SPIE routine a program check 
occurs in a program being executed for the 
issuer's task, the information contained in 
the PICA will determine the resultant pro- 
cessing of the program interruption. In 
order for the supervisor to pass control to 
the correct error handling routine, the 
supervisor must be able to test for the 
existence of a user routine. The main 
function of the SPIE routine is to place in 
the TCB of the macro-issuing program an 
indirect pointer to the user routine. If 
after a program interruption has occurred, 
the supervisor finds an address in the 
pointer field, it will pass control to the 
user routine to handle the interruption. 



Otherwise, the supervisor's Program FLIH 
will schedule an abnormal termination of 
the task whose error caused the program 
interruption . 

After the user program has issued a SPIE 
macro instruction, and the resulting macro 
expansion has constructed and initializes a 
PICA, an SVC interruption gives control to 
the supervisor. The First and Second-Level 
SVC Interruption Handlers pass control to 
the SPIE routine to complete the prepara- 
tion for user processing of a possible pro- 
gram interruption. The SPIE routine first 
determines whether to create a program 
interruption element (PIE) - The supervisor 
will store in the PIE, when a program 
interruption occurs, the information needed 
by a user-specified exit routine to handle 
the interruption. This information con- 
sists of the program check old PSW, general 
registers lU through 2, and the address of 
the current PICA. The question of whether 
to construct a new PIE hinges on whether 
the current SPIE is the first issued for 
the current task. Although there can be 
several PICAS, one for each issuance of the 
SPIE macro instruction for a given task, 
only the last specified PICA is active. 
The SPIE routine places the address of the 
newly created PICA in the PIE for the task. 
But the problem is first to determine if a 
PIE already exists for the current task. 

The SPIE routine tests for the existence 
of a PIE by examining the PIE pointer 
(TCBPIE) in the current TCB. If there is 
no PIE for the task, the current SPIE macro 
instruction must be the first issued for 
this task. In this case, the routine 
issues a GETMAIN macro instruction for the 
needed storage^ and places the address of 
the new PIE into the current TCB. The 
GETMAIN routine assigns to the storage area 
the task's storage protection key so that 
the user-specified program check routine, 
when given control, can modify the data 
stored in the PIE. 

After locating or creating the PIE, the 
SPIE routine obtains the address of the 
previous PICA from the PIE. If the PIE is 
newly created, this address is zero. The 
previous PICA address is returned to the 
caller in general register 1. If this 
register contains zero, no previous SPIE 
macro instruction was issued for the cur- 
rent task. The caller may use the old PICA 
address in a later SPIE macro instruction 
to restore to use the previous PICA. 

The SPIE routine places in the PIE, 
whether newly created or old, the address 
of the new PICA that the macro expansion 
provided as input. The PICA with its user 



^Space is allocated in subpool zero. 
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program-check routine address is then 
available to the supervisor in the event of 
a program interruption. The PIE may al- 
ready contain the address of a PICA, the 
one created by the last issuance of the 
SPIE macro instruction for the current 
task. 

As a last major function, the routine 
moves the program mask field of the PICA to 
the RB old PSW. If the PICA address in the 
PIE is zero, the current program mask field 
of the RB old PSW is saved in the first 
byte of the TCBPIE field of the current 
TCB. The new program mask, supplied as an 
input parameter, is then placed in the RB 
old PSW. By placing the program mask in 
the RB old PSW, which the Dispatcher will 
use to return control to the caller, the 
SPIE routine is effectively issuing a Set 
Program Mask instruction for the caller. 

Finally, to begin the exiting procedure 
that will complete the processing of the 
SVC interruption, the SPIE routine requests 
a supervisor-assisted linkage to the super- 
visor Exit routine. It obtains the linkage 
to the Exit routine by branching to an SVC 
3 instruction in the communications vector 
table. The SVC 3 instruction causes an SVC 
interruption which ultimately passes con- 
trol to the Exit routine. 

If the PICA address provided as input is 
zero, the SPIE routine performs the pre- 
viously described functions. However, 
since the PICA address stored in the PIE is 
zero, if a program interruption occurs, the 
Program-Check First-Level Interruption 
Handler recognizes that a user program- 
check routine has not been requested. It 
therefore branches to the ABTERM routine to 
schedule an abnormal termination of the 
task in which the program check occurred. 



SYNCHRONIZING A PROGRAM WITH ONE OR MORE 
EVENTS 

Synchronizing a program with external 
events consists of two actions : 

1. Causing a program or routine to wait 
for one or more events. 

2. Indicating the occurrence of an event 
and restarting the waiting program or 
routine. 

Causing a Program to Wait for 
One or More Events 

The purpose of the Wait SVC routine is 
to permit a user or system program to stop 
its execution until a specified number of 
events have occurred, such as the comple- 
tion of one or more I/O operations. When 
the specified events have occurred, the use 



of the Post SVC routine will indicate the 
occurrence of the awaited event or events 
and make the program ready (no longer wait- 
ing) , so that its execution may continue. 

The Wait routine performs the following 
main functions: 

• Places the program that issued the WAIT 
macro instruction into a wait condition 
so that it cannot be executed until the 
awaited event or events have occurred. 

• Recognizes those events that have al- 
ready occurred and reduces the number 
of awaited events accordingly. 

• Places in one or more special communi- 
cations areas, called event control 
blocks (ECBs), an indication that one 
or more events are awaited by the issu- 
ing program. Each ECB represents a 
unique event that is awaited. 

• Performs job-step wait limit timing for 
the step under examination. 

Like other type-1 (resident and non- 
reentrant) SVC routines, the Wait routine 
is entered from the SVC FLIH after an SVC 
interruption. The Wait routine first sets 
the system mask field of the SVC old PSW to 
all ones. It does this so that when the 
SVC old PSW is loaded to redis patch the 
caller, the caller will be enabled for I/O 
and external interruptions. This is done 
to prevent those supervisor routines that 
operate disabled and use the Wait routine 
from placing the caller into a disabled 
wait state. 

The Wait routine then checks whether a 
wait count has been specified as an input 
parameter. The wait count, or number of 
awaited events, must be specified as an 
operand of the WAIT macro instruction. If 
no wait count has been specified, as indi- 
cated by a test of register 1, the Wait 
routine ignores the request represented by 
the macro instruction and branches to the 
Type-1 Exit routine to return control to 
the caller or macro- issuing program. If a 
wait count has been specified, the Wait 
routine continues normal processing. 



The Wait routine next compares the num- 
ber of awaited events, represented by the 
wait count, with the number of event con- 
trol blocks (ECBs) that the caller has 
specified. The caller has passed to the 
Wait routine, via the coding of the macro 
expansion, the address of either a single 
event control block (for a single awaited 
event) or the address of a list of event 
control blocks if it awaits more than one 
event. The Wait routine checks the valid- 
ity of the list address and then counts the 
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number of specified ECBs. If the caller 
has specified a larger wait count than the 
number of ECBs, the WAIT request cannot be 
processed. The caller has made a serious 
error. In this case, the routine sets up 
an error code of 101 and branches to the 
ABTERM routine in order to schedule an 
abnormal termination of the calling task. 
If the number of awaited events, as indi- 
cated by the wait count, is equal to the 
number of specified ECBs, the Wait routine 
can perform the next main step of its pro- 
cessing — determining whether to test the 
validity of the input parameters passed by 
the caller. But if the wait count is less 
than the number of specified ECBs, the rou- 
tine sets a "search" flag in the request 
block (RB) of the caller. 

The reason for the setting of the search 
flag (RBECBWT bit in RBSTAB field) in the 
RB of the caller is as follows. The call- 
ing program has specified a smaller wait 
count than the number of ECBs. This means 
that the caller awaits fewer events than 
the maximum number that can occur. For 
example, the caller may await the comple- 
tion of any one of three possible I/O 
operations. In this case, the wait count 
would be one, and the number of ECBs would 
be three. When an awaited event (in this 
excimple, a single I/O completion) has 
occurred, the Post SVC routine will post 
the event in the ECB specified by the call- 
er of the Post routine. Part of the post- 
ing action consists of clearing the wait 
bit that was set previously by the Wait 
routine. Since the WAIT request has now 
been fulfilled, that is, the single awaited 
completion of three possible I/O operations 
has occurred, the wait bit remaining set in 
each of the two ECBs not yet posted is now 
misleading, and may cause later incorrect 
processing by the Post routine. The Post 
routine examines the search bit in the RB 
of the waiting program. If the search bit 
(RBECBWT) is set, the Post routine clears 
the wait bit in each of the ECBs not yet 
posted and also clears the search bit. The 
misleading indication is thus removed. 

After the Wait routine has set the 
search bit (RBECBWT) in the caller's RB (or 
if this step was bypassed because the wait 
count equals the number of ECBs) , the rou- 
tine decides whether to check the validity 
of an input parameter passed to the Wait 
routine by the caller. This parameter is 
either the address of a single ECB, or of 
more than one ECB if a list of ECBs had 
been passed. (Refer to the WAIT macro 
instruction in Supervisor Services Macro 
Instructions . ) If a system routine is the 
caller, as determined by a zero in the pro- 
tection key field of the SVC old PSW, the 
assumption is that the ECB addresses are 
correct and need no validity checking. But 
if the nonzero protection key indicates 



that a user program is the caller, the Wait 
routine decides to branch to the supervi- 
sor's Validity Check routine to test each 
ECB address that the user has specified. 

The Validity Check routine, as indicated 
previously, performs three checks of each 
input address. It determines if the 
address lies on a fullword boundary, exists 
within the boundaries of main storage, and 
designates a storage area whose storage 
protection key matches the protection key 
in the caller's TCB. If any of these tests 
fail, indicating that the caller has incor- 
rectly specified an ECB address, the Wait 
routine sets up an error code and exits to 
the ABTERM routine to schedule an abnormal 
termination of the caller's task. If all 
ECB addresses passed to the Wait routine 
are valid, or if validity checking is 
bypassed (caller is a system routine) , the 
Wait routine continues processing. 

If a validity error is detected, the 
Wait routine tests if a communications ECB 
(which is in storage with a protection key 
of zero) was specified. If yes, normal 
Wait processing continues. If a communica- 
tions ECB was not specified, the Wait rou- 
tine exits to the ABTERM routine. 

The routine next tests bits in each 
specified ECB. (See Section 12 for the 
format of an ECB. ) Wait tests the wait bit 
and completion bit in each ECB to determine 
the status of the event represented by the 
ECB. For each status the processing is 
different. If the wait bit is already set 
in any specified ECB, an error condition 
exists. One possible cause of such an 
error condition is that two programs being 
executed under the control of two different 
TCBs have specified the same ECB as an 
operand (that is, the two programs are 
awaiting the identical event) . If a wait 
bit is already set in one of the ECBs, the 
Wait routine sets up an error code (301) 
and branches to the ABTERM routine to sche- 
dule an abnormal termination of the cal- 
ler's task. 

If the wait bit is not already set in an 
ECB, Wait examines the completion bit to 
determine if the event that the caller is 
now awaiting has already occurred. A com- 
pletion bit that is set indicates that the 
awaited event represented by the ECB has 
already occurred and has been posted by the 
Post routine. In this case, the Wait rou- 
tine reduces by a count of one the speci- 
fied wait count. This is necessary because 
the caller should wait only for those 
events that have not yet occurred. When 
the routine has subtracted one from the 
wait count, it tests the remainder to 
determine if the wait count has been 
reduced to zero. If the wait count is now 
zero, all awaited events have occurred 
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(such as one I/O completion out of a possi- 
ble three completions), and the Wait rou- 
tine must perform special processing. If a 
completion bit is not set (meaning that the 
Post SVC routine has not posted this 
event's occurrence), the Wait routine sets 
the wait bit in the ECB (indicating that 
the awaited event has not yet occurred) and 
places in the ECB the address of the cal- 
ler's RB. This RB address is needed by the 
Post routine after an awaited event has 
occurred, when it wishes to adjust the wai- 
tcount stored in the RB of the waiting 
program. 

It was previously stated that for each 
completion bit that the Wait routine finds 
set in an ECB, it subtracts one from the 
specified wait count parameter. If the 
resultant wait count is zero, the required 
number of awaited events has occurred. If 
the number of needed events is less than 
the number of specified ECBs (as indicated 
by the "search" flag in the caller's RB) , 
the Wait routine must clear the wait bit in 
each ECB that has not been posted. The 
purpose of clearing the wait bit in each 
unposted ECB is to prevent the Post routine 
from later confusing an uncleared wait bit 
with a new WAIT request. This is the sctme 
function that the Post routine performs 
when it decreases a wait count to zero and 
finds the search flag (RBECBWT) set in the 
waiting RB. 

When the Wait routine has processed all 
ECBs specified in the input parameter list, 
it inserts the final wait count in the wait 
count field (RBWCF) of the caller's RB. If 
the wait count is greater than zero, the 
caller is now in the wait condition, or 
just "waiting," and cannot be dispatched. 
In this case, the Wait routine must indi- 
cate to the Type-1 Exit routine and to the 
Dispatcher that the Dispatcher must perform 
a task switch; that is, the Dispatcher must 
search the TCB queue for the next highest 
priority ready TCB, and dispatch the cur- 
rent program associated with that TCB. The 
Wait routine indicates the need for a task 
switch by clearing the "new" TCB pointer at 
location lEATCBP. The Wait routine also 
turns on the "Wait pending" flag (RBWAITP) 
in the current RB. If the final wait 
count, placed in the wait count field of 
the caller's RB is zero, the awaited events 
have already occurred and the caller must 
not wait. Therefore the Wait routine does 
not indicate to the Dispatcher the need for 
a task switch. 

After the routine has placed the wait 
count in the caller's RB, and has or has 
not indicated the need for a task switch, 
it must determine if the step under inspec- 
tion is being job- step timed. It does this 
by determining if there is a job- step TQE, 
and by testing the TCBTME field of the 



initiator TCB for a non-zero value. If the 
field is zero. Wait branches to the Type-1 
Exit routine, because the step under 
inspection has not requested job-step tim- 
ing. If the field is non-zero, indicating 
that the step has requested job-step tim- 
ing, the entire tree of tasks must be 
examined to determine if the entire step is 
in an SVC wait. Wait uses the task select 
routine to examine all the TCB's in the 
tree of tasks, beginning with the job-step 
TCB. When a TCB is found by the task 
select routine. Wait determines if the TCB 
which was just located is the TCB which 
originated the wait. If this is the case, 
the SVC old PSW is examined to determine if 
the Wait routine was entered because of the 
issuance of an SVC Wait (as opposed to a 
branch entry to Wait) . If an SVC Wait was 
issued, the task select routine is entered 
again to find another TCB. If an SVC Wait 
was not issued, and the TCB is that which 
originated the wait, the Wait Routine 
branches to the Type-1 Exit routine. If 
the TCB located by the task select routine 
is not the TCB which originated the wait, 
the Wait routine tests the task ended bit 
in the TCBFLGS bytes of the TCB. If the 
ended bit is on, the task select routine is 
entered once again to find another TCB. If 
the ended bit is not on, the Wait routine 
selects the top RB on the TCB's RB chain, 
and examines the wait count field (RBWCF) . 
If this field is zero (indicating the task 
is not waiting on any events) , the Wait 
routine branches to the Type-1 Exit rou- 
tine. If the RBWTCF field is not zero, the 
Wait routine examines the RB old PSW field 
in the TCB's top RB. If the last instruc- 
tion executed by the task currently under 
inspection (as indicated by the address 
contained in the right half of the RB old 
PSW, minus two) is an SVC Wait, the task 
select routine is entered to locate another 
TCB. If the last instruction executed was 
not an SVC Wait, the Wait routine branches 
to the Type-1 Exit routine. 

When the task select routine can find no 
more TCBs in the tree of tasks (indicating 
that the entire tree of tasks is in an SVC 
Wait) , the Wait routine uses the Dequeue 
TQE (entry point lEAQTDOl) routine in the 
Timer Second Level Interruption Handler to 
remove the job-step TQE from the timer 
queue. The Wait routine next converts the 
job-step TQE from a task TQE to a 30-minute 
wait limit TQE while saving the CPU remain- 
ing time in the reserved slot of the TQE. 
If the System Management Facility is 
included in the system, the Wait routine 
checks the initiator TCB for the address of 
a timing control table (TCT) . If there is 
a TCT, the job-step wait time limit, not 
the 30-minute wait limit, is placed in the 
TQE. The job-step wait time limit appears 
in the TCTWLMT field of the TCT. If there 
is no TCT, the 30 minute value is used. 
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The TQE is then enqueued on the timer 
queue by the Enqueue TQE routine (entry 
point lEAQTEOO) . The job-step timing 
algorithm necessitates job-step TQE 
manipulation. 

When a tree of tasks is in an SVC wait, 
the step is not CPU timed. But because of 
the possibility of a Wait on an ECB which 
will never be posted, job- step timing 
requires that a wait limit TQE be imposed 
on a step. The effect of the wait limit 
TQE would be to abnormally terminate a step 
which has waited on an event (s) for more 
than a specified amount of time (30 
minutes), without having the event (s) 
occur. 

After the routine has or has not con- 
verted the job-step TQE, it branches to the 
Type-1 Exit routine to start the retuim to 
a main-line program. The Type-1 Exit rou- 
tine tests the TCB pointers, lEATCBP and 
lEATCBP+U. If the need for a task switch 
has been indicated by the inequality of the 
two TCB pointers, the Type-1 Exit routine 
branches to the Dispatcher to perform a 
search of the TCB queue, and to return con- 
trol to the current program of another 
task. If a task switch has not been indi- 
cated, the Type-1 Exit routine loads the 
SVC old PSW to give control directly to the 
caller. Since in this case all specified 
events have already occurred, the caller 
does not wait, except for supervisor 
processing. 

Indicating the Occurrence of an Event and 
Restarting a Waiting Program 

The Post SVC routine permits a program 
(the "posting" program or caller) to signal 
the occurrence of an event, such as the 
completion of an I/O operation, awaited by 
a waiting program. The routine signals 
(posts) the event's occurrence by altering 
one of two bits in a specified event con- 
trol block (ECB) shared by both waiting and 
posting programs. The Post routine places 
in the event control block a "post code" 
supplied by the posting program- The post 
code may later be inspected by the waiting 
program, after it resumes execution, to 
determine the type of event that occurred. 
The Post routine determines if the program 
that is awaiting the posted event can be 
made ready (that is, whether all awaited 
events have occurred) . 

If the waiting program can be made 
ready, and belongs to a task of higher dis- 
patching priority than that of the posting 
program, the Post routine indicates to the 
Dispatcher that a task switch is needed 
(that is, a ready program whose TCB is of 
higher priority than that of the caller 
should be dispatched) . The Post routine 
determines if the initiator TCB of the TCB 



being posted has a TQE (the job-step TQE) 
which indicates the step is being job step 
timed. If a job-step TQE does exist, and 
it is a 30 minute wait limit TQE, the Post 
routine dequeues the TQE from the timer 
queue and converts the element to a task 
TQE. 

There are three branch entry points to 
the Post routine. One (IGC002+6) is used 
exclusively by supervisor routines. A 
second (lEAOPTOl) is used exclusively by 
the I/O supervisor. The third (IEAOPT02) 
is used by both the I/O Supervisor and 
supervisor routines vdien they need to check 
the validity of user-specified ECBs. The 
I/O Supervisor's branch entry permits the 
I/O Supervisor to pass parameters in regis- 
ters different from the standard registers, 
and also permits the saving of registers 
across the Post routine. 

On branch entry from the I/O Supervisor, 
the Post routine saves the input registers, 
places the input parameters in the standard 
registers, and branches to the main-line 
part of the Post routine. On return from 
the main-line part of the Post routine, the 
saved registers are restored and control is 
returned to the I/O Supervisor- In this 
case, any task switch whose need is indi- 
cated by the Post routine does not occur 
until the I/O Supervisor branches to the 
Dispatcher, via the I/O FLIH. 

On branch entry from a supervisor rou- 
tine, the Post routine assumes that the 
input parameters are in the standard regis- 
ters. This entry allows a supervisor rou- 
tine to post an event without causing a 
task switch until the caller of the Post 
routine exits, instead of occurring when 
the Post routine exits. 

With any branch entry, the Post routine 
returns control to the calling routine. 
But if the Post routine is entered via an 
SVC interruption, it exits via the Type-1 
Exit routine. 

If the TJID is specified for a time 
sharing task and the TCBINCOR flag in the 
terminal job block indicates that the task 
is not in main storage, an Inter-partition 
post block is created to record the 
requested post. The Post routine then 
issues a TSEVENT macro instruction specify- 
ing that the task whose ECB is to be posted 
be brought into main storage ( swapped- in) . 

The main- line part of the Post routine 
first determines if validity checking is 
necessary. Validity checking is bypassed 
if either of the exclusive branch entries 
is used, or if the entry is from the SVC 
FLIH and the calling program is a system 
routine. (A system routine operates with 
protection key of zero.) In these cases. 
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the assumption is that the calling routine 
has passed a valid ECB address. 

If validity checking is necessary, the 
Post routine determines that the ECB 
address passed by the caller is valid. 
Then, if the wait bit is set in the speci- 
fied ECB, it checks the validity of the RB 
address contained in the ECB. The Post 
routine branches to the supervisor* s Valid- 
ity Check routine to perform the needed 
address checking. 

The Validity Check routine, as indicated 
in the discussion of the Wait routine, per- 
forms three checks of an ECB address. It 
determines if the address lies on a full- 
word boundary, exists within the boundaries 
of main storage, and designates a storage 
area whose storage protection key matches 
the protection key in the caller's TCB. If 
any of these tests fails, indicating that 
the caller has incorrectly specified an ECB 
address, the Post routine sets up an error 
code (102) and exits to the ABTERM routine 
to schedule an abnormal termination of the 
caller's task. If a validity check of the 
ECB address is bypassed, a check is made to 
determine if this is an Inter-Partition 
Post. If it is. Post parameters are 
obtained from the user parameter list. If 
it is not, the Post routine continues 
processing. 

The next step is to check the completion 
bit in the specified ECB. If the comple- 
tion bit is set, indicating that the event 
now being posted has already been posted, 
there is no need for further processing. 
The Post routine treats this condition as a 
no-operation, and branches to the Type-1 
Exit routine or to the caller. 

If the Post routine was entered at a 
branch entry, it branches to the calling 
routine instead of to the Type-1 Exit rou- 
tine. This is done without special tests. 
The Post routine branches to the address in 
the return register, general register m. 
If the routine was entered from the SVC 
FLIH, general register IH contains the 
address of the Type-1 Exit routine. But if 
the routine was entered at a branch entry 
point, general register IH contains the 
return address of the caller. 

If the completion bit is not set, the 
event represented by the ECB has not pre- 
viously been posted, and processing can 
continue. 

The Post routine next tests the wait bit 
in the specified ECB. If the wait bit is 
set, the Post routine must check the valid- 
ity of the RB address contained in the ECB. 
This is the address of the RB for the pro- 
gram that awaits the event now being post- 
ed. The RB address was placed in the ECB 



by the Wait routine ^en it serviced the 
WAIT macro instruction issued by the now- 
waiting program. Since the ECB is part of 
user-specified storage, and may have been 
modified by a user program after the Wait 
routine stored the RB address of the wait- 
ing program, the Post routine must now 
check the RB address. 

The post routine performs the check by 
making four tests. The first test deter- 
mines whether the RB address is on a full- 
word boundary and is within machine- 
specified storage. The second test checks 
whether the old PSW field (RBOPSW) of the 
RB specified by the address is enabled for 
system interruptions. The third test com- 
pares the protection key in the RB old PSW 
of the specified RB with the protection key 
in the RB old PSW of the waiting program's 
RB. The fourth test determines whether the 
last-executed instruction of the waiting 
program, located via its RB old PSW field, 
was a WAIT macro instruction (SVC-1) . If 
any of these tests fail, indicating that 
the RB address has been altered, the Post 
routine sets up an error code (202) and 
branches to the ABTERM routine to schedule 
an abnormal tearmination of the caller's 
task. If, however, the RB address appears 
valid, or the wait bit had not been set, 
indicating that the now posted event is not 
yet awaited, the Post routine continues 
processing. 

The Post routine places in the specified 
ECB information useful to the waiting pro- 
gram and to the Wait and Post routines. 
The routine stores in the ECB a Post code 
specified as an operand of the POST macro 
instruction. The post code can supply to 
the waiting program, when it resumes execu- 
tion, information al30ut the event's occur- 
rence. Besides storing the post code in 
the ECB, the Post routine sets the comple- 
tion bit and clears the wait bit. These 
bits now indicate to both the Wait and Post 
routines, and also to a user progrcun if it 
inspects the ECB, that the event repre- 
sented by the ECB has occurred and is not 
now awaited. 

The Post routine must next determine 
whether to decrease the wait count stored 
in a waiting program's RB. The wait count, 
stored in the RBWCF field of a waiting pro- 
gram's RB, indicates the number of awaited 
events that must occur before the program 
can resume execution. As long as the wait 
count stored in an RB is greater than zero, 
the program represented by the RB may not 
be dispatched. 

The Post routine tests if the wait count 
in the waiting program's RB is already 
zero. This can occur in the special case 
in which the waiting program's task was 
abnormally terminated, via ABTERM, because 
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of an event asynchronous to the waiting 
program. The ABTERM routine resets to zero 
the wait count in the top RB on the RB 
queue of the TCB for which it is scheduling 
an abnormal termination. In this case, the 
Post routine returns control to the caller 
without changing the wait count in the 
waiting program's RB. 

If the event is awaited, as indicated by 
a nonzero wait count, the routine subtracts 
one from the wait count field (RBWCF) of 
the waiting program's RB. It then tests 
the remaining wait count to determine if 
the waiting program can be made ready (that 
is, whether the new wait count is now 
zero). If the new wait count is not zero, 
all events awaited by the program have not 
yet occurred, and further processing is not 
possible. In this case the Post routine 
returns control to the caller, or posting 
program, either directly if the caller is 
the I/O Supervisor, or via the Type-1 Exit 
routine. If, however, the new wait count 
is zero, indicating that the posted event 
is the last needed by the waiting program, 
the Post routine turns off the "Wait pend- 
ing" flag (RBWAITP) and further processing 
occurs . 

The Post routine next determines if the 
posted ECB is part of a list of ECBs. In 
other words, is the minimum number of 
awaited events (the wait count) less than 
the number of specified ECBs (for example, 
one needed I/O completion among three poss- 
ible I/O completions)? If the answer is 
yes, one or more unposted ECBs exist whose 
wait bits remain set. These ECBs will 
cause error in future processing by the 
Post routine. The wait bits must be 
cleared. To determine if there are remain- 
ing unposted ECBs associated with the pro- 
gram whose wait count is now zero, the Post 
routine tests the "search" bit (RBECBWT) in 
the RB of the waiting program. If the bit 
is set (see discussion of Wait), the Post 
routine assumes that the number of awaited 
events is less than the number of specified 
ECBs. It obtains the address of the ECB 
list belonging to the waiting program, 
checks the validity of the list, and clears 
the wait bit in each outstanding ECB of the 
list. 

After all unposted wait bits have been 
cleared, or if no unposted wait bits 
remained, the Post routine tests the TCBTME 
field of the initiator TCB of the task 
which is being posted. If the field is 
zero, it indicates that job-step timing is 
not being performed for this step, and the 
Post routine would test if the program may 
be dispatched. If the field is non-zero, 
the Post routine examines the TQE type — 
REAL or TASK. If the TQE is TASK type, it 
indicates that the entire tree of tasks was 
not in an SVC wait, and the Post routine 



would then test if the program may be dis- 
patched. If the TQE is REAL and on the 
timer queue, it indicates that a 30-minute 
wait limit TQE had been placed on the timer 
queue. If such is the case, the Post rou- 
tine would branch to the Dequeue TQE rou- 
tine (entry point lEAQTDOl) in the Timer 
Second-Level Interruption Handler to remove 
the element from the queue. The Post rou- 
tine would reinstate the actual CPU time 
remaining value in the TQEVAL field of the 
TQE. It would then mark the TQE as TASK 
type. This processing would allow the Dis- 
patcher to once again calculate the CPU 
time used by this job step. 

After the Post routine had or had not 
manipulated the job-step TQE, it tests if 
the program whose wait count is now zero 
may be dispatched. The Post routine 
branches to the Task Switching routine to 
perform three tests. One test determines 
that the RB of the waiting program is at 
the top of its task's RB queue, and is 
therefore the current program for its task. 
An RB is at the top of its RB queue if it 
is pointed to directly by its TCB. The 
second test determines that special non- 
dispatchability bits (TCBFLGS field) have 
not been set in the TCB for the waiting 
program's task. If both tests are success- 
ful, a third test determines if the TCB of 
the waiting program has a higher dispatch- 
ing priority than the TCB of the posting 
program. 



If any of the tests fails, the Post rou- 
tine returns control to the caller, or 
posting program, either directly (if the 
caller is the I/O Supervisor) or indirect- 
ly, via the Type-1 Exit routine. If the 
tests show that control should be returned 
to the waiting program, the Post routine 
indicates the need for a task switch by 
setting the "new" TCB pointer at lEATCBP to 
the address of the waiting program's TCB. 
The Post routine then returns control to 
the caller. If the return is indirect 
through the Type-1 Exit routine, the Type-1 
Exit routine branches to the Dispatcher to 
perform the task switch. If the return, 
after the branch to the Post routine, is 
directly to the caller, the task switch 
does not occur until the caller itself 
branches to the Type-1 Exit routine or to 
the Dispatcher. 



SERIALIZING THE USE OF A RESOURCE 

The ENQ routine, working with the DEQ 
routine, permits programs issuing the ENQ 
macro instruction (or, in systems that 
include the shared DASD feature, the 
RESERVE macro instruction) to gain one-at- 
a-time access to a resource or set of 
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resources. The requested resource may 
include one or more data sets, records 
within a data set, programs, or work areas 
within main storage. The routine places in 
a resource queue all resource requests 
specified in the caller's macro instruc- 
tion. If no other ENQ-issuing program is 
using any of the requested resources, the 
ENQ routine, via the Exit routine and the 
Dispatcher, returns control to the caller, 
which then gains access to its resource (s). 
But if any of the caller's resources are 
already in use by another ENQ-issuing pro- 
gram, being executed for another task, the 
ENQ routine places the caller in a wait 
condition until the resource becomes avail- 
able. When the program that is using the 
resource (s) completes its use, it issues a 
DEQ macro instruction that causes the DEQ 
routine to remove one or more elements from 
the request queue, and reduce the wait 
count for the waiting program. If the wait 
count is now zero, the DEQ routine, via 
theExit routine and the Dispatcher, may 
return control to the previously waiting 
(now ready) program. The program then 
gains access to its resource(s). 



Separate although related functions are 
needed when a resource is requested and 
when the use of the resource is signaled 
complete. The functions may be listed 
under the headings of major and minor func- 
tions. Major functions are those which 
satisfy the principal purpose of the ENQ 
and DEQ macro instruction. Minor func- 
tions, although also important, are not 
related to the central purpose of the macro 
instructions. For example, the validity 
checking of input addresses may be consid- 
ered a minor function. 



Types of Resource Requests 

There are two types of resource requests 
which may be specified by the ENQ-issuing 
program: an "exclusive" (E) request or a 
"shared" (S) request. The ENQ routine 
handles these two types of requests dif- 
ferently. An exclusive request is treated 
strictly on a first- in, first-out basis. 
That is, an exclusive request in the queue 
may not be serviced until all earlier 
requests of either type have been serviced. 
Also, later requests of either type may not 
be serviced until a previously entered 
exclusive request has been handled. A 
"group" of shared requests, however, if 
placed consecutively in the queue, may be 
serviced as a group, if one of the shared 
requests is at the top of the queue. That 
is, the group of shared requests is honored 
strictly on a task-priority basis. Figure 
3-5 illustrates the handling of typical 
combinations of shared and exclusive 
resource requests. 



Description of the Resource Queues 

Before the discussion can proceed, the 
reader must become familiar with the con- 
struction of the resource queues and the 
nature of the search for already existing 
resource requests. Each resource request 
contained in the ENQ macro instruction spe- 
cifies a Qname, which names a set of 
resources, and an Rname which names a 
single resource within the set identified 
by the Qname. The Qname, specifying a set 
of resources, is represented on the 
resource queues by a major queue control 
block, or major QCB. Each major QCB con- 
tains, besides pointers to other control 
blocks, the Qname for a set of resources, 
for example, the name of a data set. A 
major QCB thus represents a set of 
resources. 

Each major QCB points to a minor QCB, 
which represents a particular resource 
within the set of resources, for example, a 
specific record within a data set. As the 
reader may expect, a minor QCB contains, 
besides pointers, an Rname which is the 
name of the particular resource that has 
been requested. Each minor QCB, if another 
resource within the set has been requested, 
points to another minor QCB. Thus, each 
minor QCB represents a particular resource 
that has been requested within a set of 
resources represented by a major QCB. 

Each minor QCB contains the list origin 
for a queue of one or more queue elements, 
or QELs. Each QEL represents a request for 
a single resource by a program belonging to 
a specific task. If a program requests 
more than one resource, the ENQ routine 
constructs two or more QELs, each repre- 
senting a request. If all the QELs that 
represent resource requests by a program 
are at the top of their respective QEL 
queues, the program may use the resources. 
That is, the program is not waiting and can 
gain access to the resources as soon as it 
is dispatched. But if all the QELs that 
represent requests by a program are not at 
the top of their respective QEL queues, the 
requesting program must wait. The using 
program must complete its use and issue a 
DEQ macro instruction. The DEQ routine 
moves the next QEL to the top of the queue. 
The task may be dispatched when all of its 
QELs are at the top of their respective 
queues, or in a group of shared requests at 
the top of the queue. 

Figure 3-6 illustrates the resource 
queues. In Figure 3-6, program X is using, 
or is about to use, the resources repre- 
sented by major QCB 1 and minor QCBs 1 and 
2. Its requests are at the top of the 
queues, represented by QELs 1 and 2. Pro- 
gram Y has requested one of the resources 
being used by program X, that represented 
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condition 1; 

A group of shared 
requests is at the top 
of the resource queue. 



Condition 2; 

An exclusive request 
at the top of the queue 
is followed by a group 
of shared requests. 



shared request 



shared request 



exclusive request 



exclusive request 



shared request 



shared request 



The resources are used by 
the shared requesters on 
a task-priority basis. 
The exclusive requester 
waits until the shared 
requesters have completed 
their use of the resource 
and have removed their 
requests from the queue. 



The exclusive requester 
has access to the re- 
source. The shared re- 
questers wait until the 
resource is free. They 
then share the resource 
on a task-priority basis. 



Condition 3; 

An exclusive request 
at the top of the queue 
is followed by a second 
exclusive request. 



exclusive request 



exclusive request 



The first (top) exclusive 
requester uses the re- 
source while the second 
exclusive requester waits. 
When the first requester 
has completed its use of 
the resource, the second 
requester can proceed. 



Condition 4; 

A group of shared 
requests is at the top 
of the queue, followed 
by an exclusive request - 
The exclusive request 
is followed by a group 
of shared requests. 



i shared 


request | 


1 shared 


.. , ^ 

request | 

J 




r ~ 1 

[exclusive request) 


1 shared 


1 
request | 




1 shared 


1 
request | 



The resource is first 
shared on a task-priority 
basis ty the shared 
requesters whose requests 
are at the top of the 
queue. The exclusive 
requester waits iintil the 
shared requesters have 
completed their use of the 
resource and have removed 
their requests from the 
queue. The exclusive 
requester then has 
exclusive access to the 
resource. The shared 
requesters lower on the 
queue wait until the re- 
source is available- They 
then share the resource on 
a task-priority basis. 



Figure 3-5. The Handling of Shared and Exclusive Requests 
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Module lEAQCBOl 









1 First QCB^ 


save area 1 


8 


^^^ save area 


16 


^^,^^-'^ "HEADQCB" 
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Major QCB 1 



Minor QCB 1 



-Minor QCB Queue - 
Minor QCB 2 



-i 



Major 

QCB 

Queue 



Po'inhs to next ' 
or last major 
QCB on the queue 
(if one exists) 




QEL 
Queues 



Program X 


Program Y 



NOTES: 1. Arrows represent pointers. 

2. Each combination of a major QCB, a minor QCB, and a QEL represents a resource requested for a particular task, 

3. Program X is using resources Rname 1 and Rname 2. 

4. Program Y awaits resource Rname 2. 



Figure 3-6. The Resource Queues 



by major QCB 1 and minor QCB 2. Since the 
resources desired by program Y is already 
in use, the program must wait, its request 
remaining on the queue as QEL 3. 



Note that each requested resource is 
represented by a combination of one major 
QCB and one of its associated minor QCBs. 
Each request is represented by a queue ele- 
ment (QEL) , which points to the TCB asso- 
ciated with the requesting program. If 
there is not at least one QEL for a pre- 
viously requested resource, the DEQ rou- 
tine, when the DEQ macro instruction is 
issued, removes the associated minor QCB. 
(Under certain conditions the DEQ routine 
also removes a major QCB.) Thus, if there 
are control blocks — major QCB, minor QCB, 
and QEL — on the resource queues, there 
must be at least one request for a resource 
whose use has not yet been completed. 

Requesting One or More Resources 

The functions needed when a resource is 
requested may be listed under the headings 



of major and minor functions. Major func- 
tions are those which satisfy the principal 
purpose of the ENQ macro instruction. 
Minor functions, although also Important, 
are not related to the central purpose of 
the macro instruction. For example, valid- 
ity checking of input addresses may be con- 
sidered a minor function. 

MAJOR FUNCTIONS ; When one or more 
resources are requested, via the ENQ macro 
instruction, the major functions are: 

• If necessary, creation of one or more 
queue control blocks (QCBs) to repre- 
sent the requested resource, and the 
placing of these queue control blocks 
on the resource queues. 

• Depending on the RET parameter, the 
creation of a queue element (QEL) to 
represent the request, and the place- 
ment of the QEL on a QEL queue. 

• If the resource is available, the 
returning of control to the requester, 
with or without a return code that 
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indicates the availability of the 
resource, depending on the RET 
parcuneter. 

If the requested resource is not avail- 
able, either of two functions are per- 
formed, depending on the RET parameter: 

- The requester is placed in a wait 
condition, pending the availability 
of the resource, or 

- Control is returned to the requester 
with a code that indicates that the 
resource is unavailable. 



The first major function, performed by 
the ENQ routine, is to search the resource 
queues to determine if the requested 
resource is already in use. The ENQ rou- 
tine searches the major QCB queue for a 
major QCB that contains the specified 
Qname. If it finds the Qname, at least one 
resource in the set of resources is in use, 
and the routine then searches the asso- 
ciated minor QCB queue for the Rname. 

When the time sharing option is included 
in the system, step enqueue for a time 
sharing task causes the TJID to be placed 
in the minor QCB, in the first byte of the 
first QEL, and in the first byte of the 
previous minor QCB field. 

PROCESSING IF THE REQUESTED RESOURCE IS NOT 
IN USE ; If the requested resoiirce is not 
in use, as indicated by the absence of QCBs 



with the specified Qname and Rname, control 
is returned to the caller. Depending on 
the RET code supplied by the caller, a 
return code may or may not be issued, and a 
QEL may or may not be constructed and 
placed on the resource queues. (Refer to 
Figure 3-7 for the various results.) 



PROCESSING IF THE REQUESTED RESOURCE IS IN 
USE ; If another requester has access to 
the resource, as indicated by a major and 
minor QCB containing the resource names, 
the resultant processing varies. It 
depends on the particular RET option that 
the caller has specified, on the type of 
request — shared (S) or exclusive (E) — 
and on the types of QEL' s already on the 
queue. (The RET-parameter formats and the 
QEL formats appear in Section 12 of this 
manual.) Figure 3-8 lists the different 
forms of resultant processing. 

Note in Figure 3-8 that a QEL is con- 
structed and placed on a QEL queue if the 
requester wants access to the resource and 
is willing to wait for it. The requester's 
willingness to wait for the resource is 
indicated by a RET option of HAVE, NONE, or 
the omission of the RET operand. The RET 
option of TEST or CHNG never causes crea- 
tion of a QEL, only the generation of a 
return code (see Figure 3-9) indicating 
whether the resource is available. If RET 
is USE, a QEL is created only if the re- 
quester can have immediate access to the 
resource (Part 2 of Figure 3-8). 



RET Parameter 
I 



Meaning of RET Parameter 



QCB and/or QEL 

Constructed and 

Queued 



Control is 
Returned to 
Caller with 
Code of: 



Meaning of 
Return Code 



TEST 



h 



CHNG 



1 

USE 



Tests the queues to determine if 
the caller can have immediate use 
of the resource. Never con- 
structs control blocks. 



no 



Resource is 
available 



4- 



Requests a change of attribute 
from shared to exclusive on a 
resource for which the caller is 
enqueued. Never constructs 
control blocks. 



— + 



-H 



no 



Caller not 
enqueued 
for re- 
source 



1 

Resource is 
available 



HAVE 



Places QCB and/or QEL on queues 
only if caller can have immediate 
access to the resource. 



yes 



Delay can be tolerated. Places 
QCB and/or QEL on queues - 



-— + 



yes 



Resource is 
available 



-■1 



NONE or 
omitted 



Same as HAVE but produces no 
return code. 



yes 



no code 



Figure 3-7. Processing if a Requested Resource Is not in Use 
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Type of Previous QEL 
and Present Request 
I 

1. The previous QEL on the 
queue is "exclusive," 
or the present request 
is "exclusive." 



I 

2. The previous QELs and 
the present request are 
both "shared," or 



There is no previous 
QEL for the resource 
(that is, the QEL queue 
is empty). 



RET parameter 
is: 



USE or TEST 



HAVE, NONE or 
omitted 



TEST 



^ 

NONE or omitted 



Resultant Processing 



Sets return code equal to k and, via the 
Exit routine and the Dispatcher, returns 
control to the caller. A QEL is not con- 
structed to represent the request. 



Places requester into wait condition by in- j 



creasing SVRB wait count, constructs a QEL 
and places it on a QEL queue, indicates 
that a task switch is needed, branches to 
the Dispatcher to perform a task switch. 
If RET is HAVE, a return code of is also 
produced.^ 



I 



Sets return code equal to and, via the 
Exit routine and the Dispatcher, returns 
control to the caller. No QEL is con- 
structed. 



H 



Constructs a new QEL, places it on a QEL | 

queue, and via the Exit routine and the j 

Dispatcher, returns control to the caller, j 

[ ___4 ___ 1 

USE or HAVE |Sets return code equal to 0, constructs a | 
new QEL, places it on a QEL queue, and via j 
the Exit routine and the Dispatcher, j 
returns control to the caller. j 

i i X _ __ ^ 

I^This return code is passed to the requester only after the resource becomes available. | 
L I 

Figure 3-8. Processing if a Requested Resource Is in Use 



j code 
I 



h- 



f- 



Meaning 



RET = TEST 



RET = USE 



I 



RET = HAVE 



RET = CHNG 



The resource is 
immediately avail- 
able. 



Control of the resource has been 
assigned to the active task. 



-~+- 



The Resource is not immediately 
available. 



N/A 



, 

Control of the | 
resource has been j 
assigned to the j 
active task. Either j 
the user was al- j 
ready enqueued for | 
the resource with j 
the exclusive j 
attribute or the j 
requested change j 
from shared to j 
exclusive was j 
honored. 



Requested change in| 
attribute cannot bej 
honored at this j 
time. I 

^ 

The requesting task| 
was not enqueued j 
for the resource | 
when the attribute j 
change from shared j 
to exclusive was j 
requested- j 
J 



A previous request for control of the same resource has 
been made for the same task. 



L i 

Figure 3-9. 



Return Codes for the ENQ Routine 
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Note that if all previous QELs on the 
queue and the present request are both for 
"shared" resources, there is no need for 
the caller to wait. The new requester and 
those represented by the "shared" previous 
QELs on the queue may share the resource on 
a task-priority basis. Thus, a requester 
need not have its QEL at the top of the 
"shared" group of QELs. Any requester 
represented in the shared group may be 
executed if other requesters represented in 
the group are waiting for an event, such as 
an I/O completion, provided at least one 
member of the group is at the top of the 
queue. 

RETURNING CONTROL ; Control is returned to 
the caller if the requested resource or 
resources are available, or to the current 
routine of the next highest priority ready 
task if the caller must wait because the 
requested resource is in use. If the call- 
er is to receive control, the return path 
is via the Exit routine and the Dispatcher. 
But if the current routine of another task 
is to receive control, the return path is 
via the Dispatcher only. To determine the 
appropriate return path, the ENQ routine 
tests the RB wait count field in the cur- 
rent SVRB. If the RB wait count is zero, 
all requested resources are available and 
the caller can receive control. But if the 
RB wait count is greater than zero, the 
caller is effectively in a wait condition 
and cannot be given control. 

If the caller can receive control, the 
ENQ routine branches to the Exit routine to 
remove the SVRb from its RB queue and free 
the storage area it occupies. The Dis- 
patcher then returns control to the caller 
by loading the RB old PSW contained in the 
caller's RB. 

If the caller cannot be given control, 
the ENQ routine prepares for the caller's 
future restart. It does this by changing 
the SVRB old PSW to point to the SVC 3 
instruction in the Communications Vector 
Table. When in the future the DEQ routine 
permits the caller's task to regain con- 
trol, the first instruction to be executed 
will be the SVC 3, which causes supervisor 
linkage to the Exit routine to remove the 
SVRB. 

After preparing for the caller's future 
restart, the ENQ routine indicates to the 
Dispatcher that it should search the TCB 
queue for the next highest priority ready 
TCB. The indication to the Dispatcher is 
the setting of the "hew" TCB pointer 
(lEATCBP) to zero. Then the routine 
branches to the Dispatcher to search down 
the TCB queue to find the next highest 
priority ready TCB. When it finds the TCB, 
the Dispatcher places in execution the cur- 
rent routine of the associated task, by 



loading the RB old PSW contained in the 
current RB- 



MINOR FUNCTIONS: 



When one or more 



resources are requested, the minor func- 
tions are the: 

• Setting of the caller' s task in "must 
complete" status, if specified, and if 
the caller is a system task. 

• Detection of abnormal conditions that 
can cause the generation of an error 
code or the abnormal termination of the 
caller's task. 

• Purge of QELs from the resource queues 
for an abnormally terminated task. 

• Increasing of the "enqueue count" in 
the requestor's TCB. 

• Increasing by a count of one the "non- 
rolloutable count" (TCBNROC) in the 
caller's job step TCB. 

If the "set must complete" parameter is 
specified, the ENQ routine permits accel- 
erated completion of the caller's task by 
setting nondispatchable all other tasks in 
the job step or system. To prevent schedu- 
ling of an abnormal termination of the cal- 
ler's task, the ENQ routine places a spe- 
cial "must complete" flag in the TCB for 
the caller's task to serve as an indicator 
to the ABTERM and ABEND routines. 

If a time sharing task has requested 
"set must complete" processing, a TSEVENT 
macro instruction with the REQSTMC operand 
is issued to indicate to the time sharing 
driver that ENQ processing is not to be 
interrupted. 

Invalid input-list addresses and duplic- 
ate resource requests for the same task are 
detected. A duplicate resource request is 
caused by two ENQ macro instructions for 
the same resource and task without an 
intervening DEQ macro instruction. (If 
RET=CHNG, an error condition does not exist 
since the caller must be previously 
enqueued in order to request a change in 
attribute.) These error conditions result 
in either a return code and return of con- 
trol to the caller, or an error code and 
the abnojnnal termination of the caller's 
task via the supervisor linkage to the 
ABEND routine. 

The AUTOPRG subroutine is used when the 
ABEND routine, or a routine invoked by 
ABEND, issues an ENQ macro instruction dur- 
ing an abnormal task termination. It con- 
sists of a purge of resource requests 
(QELs) , and, if necessary, QCBs belonging 
to tasks that are being abnormally ter- 
minated. Since the QELs cannot be removed 
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by their original requester via the DEQ 
macro instruction, they are removed from 
the resource queues by the AUTOPRG subrou- 
tine to make the requested resource avail- 
able to the ABEND routine. 

An "enqueue count" is maintained in the 
requester's TCB. The enqueue count is 
stored in TCBQEL, the high-order byte of 
the TCBFSA field. The count is increased 
by the ENQ routine for each resource requ- 
est and decreased by the DEQ routine when 
the use of the resource is signaled com- 
plete. The enqueue count is tested by the 
supervisor's EOT routine when the reques- 
ter's task is terminated normally. The 
test determines if all resource requests 
previously created for the task via ENQ 
macro instructions have been removed via 
corresponding DEQ macro instructions. 

Placing the Caller's Task in "Must Com- 
plete" Status ; The "set must complete" 
function is used by system programs^ to 
allow the programs of one task to be 
executed while the programs of other tasks 
in the job step (STEP option) or other 
tasks in the system (SYSTEM option) are 
held nondispatchable, unable to be 
executed. The purpose is to prevent the 
abnormal termination of the "must complete* 



^The test is for zero protection key in the 
requester's RB old PSW. 



task by a routine belonging to another task 
in the job step or in the system. If a 
routine being executed for the "must com- 
plete" task produces a program check, the 
ABEND routine terminates the task by set- 
ting it and its related tasks nondispatch- 
able. A message is issued to the operator 
indicating that a CPU wait state has been 
averted and that no more jobs should be 
scheduled. Jobs that are already scheduled 
are allowed to reach normal termination. 
(See the description of ABENDl in "Termina- 
tion Procedures.") 



The ENQ routine makes several checks to 
determine if the requester's task should be 
set in "must complete" status (see Figure 
3-10). The ENQ routine tests whether the 
following requirements have been met: 

• The requester is a system routine, as 
indicated by a zero protection key in 
the requester's RB old PSW. 

• The RET operand of the ENQ macro 
instruction is not TEST. 

• The SMC ("set must complete") operand 
of the ENQ macro instruction has been 
specified. 

• The current SVRB is in a ready condi- 
tion. (A ready condition is indicated 
by a RBWCF field of zero.) 



h 



Common Name 



"Must Complete" 
nondi spatch- 
ability flag 
(system or job 
step) 



I- 



l 

"Must Complete" 
flag (system or 
job step) j- 



Symbolic 
Name 



TCBSYS 



TCBSTP 



--+ 



Displacement 
in TCB 



33.4 



33.5 



TCB(s) in Which Flag 
is Set 



All TCBs in system, 
except "must complete" 
TCB and certain system 
TCBs^ 



H 



All TCBs in job step 
except "must complete" 
TCB 



Purpose of Flag When Set 



Indicates to the Dis- 
patcher that it may not 
place into execution any 
routine associated with 
this TCB. 



H 



TCBFSMC 



30.3 



'Must complete" TCB 



Prohibit asyn- 
chronous exits 
flag 



TCBFJMC 



f 

TCBFX 



30.4 



29.7 



Must complete" TCB 



If this task is in error, 
indicates to the ABEND 
routine that the task 
should be terminated and 
the system be allowed 
to qpiiesce via the 
System Quiesce routine. 



Indicates to the Stage 3 
Exit Effector that it 
should not schedule a 
user exit routine for 
this task. 



I X X 

^The system TCBs that are not flagged 
rollout/rollin TCB, the system error 



nondispatchable are the communications TCB, the 
TCB, and the transient area fetch TCBs. 



Figure 3-10. TCB Flags that are Set if a Task Is in "Must Complete" Status 
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The processing varies, depending on the 
outcome of the tests. If all requirements 
have been met, the ENQ routine performs 
"set must complete" processing. To perform 
"set must complete" processing the ENQ rou- 
tine invokes the Set Status routine 
CIGC079) via the STATUS macro instruction. 
If the request is for step "must complete" 
status, it sets the "step must complete" 
nondispatchability flag (TCBSTP) in all 
TCBs of the job step except the requester's 
TCB. (The job-step's Initiator is also set 
nondispatchable. ) If the request is for 
system "must complete" status, the ENQ rou- 
tine sets the "system must complete" non- 
dispatchability flag (TCBSYS) in all TCBs 
of the system, except the requester's TCB 
and the TCBs of certain system tasks. The 
System tasks that remain dispatchable are 
the communications task, the rollout/rollin 
task (if the rollout feature is included) , 
the system error task, and the transient 
area fetch tasks. The "must complete" non- 
dispatchability flags indicate to the Dis- 
patcher that it may not place in execution 
the routines controlled by these TCBs. 

As part of "set must complete" process- 
ing, the ENQ routine also sets two flags in 
the requester's TCB. One flag, when set, 
prevents the Stage 3 Exit Effector from 
scheduling user exit routines for the 
requester's task. This precaution prevents 
the initiation of an abnormal termination 
in a user exit routine while the task is in 
"must complete" status. The other flag, 
when set, causes the ABEND routine to 
branch to the system quiesce routine if an 
abnormal termination is initiated during 
performance of the "must complete" task. 
The system quiesce routine teirminates the 
"must complete" task and its subtasks and 
issues a message to the operator indicating 
that a CPU wait state has been averted and 
that the system should be allowed to 
quiesce (that is, no more jobs should be 
scheduled and the jobs that are already 
scheduled should be allowed to reach normal 
termination) . 

If all requirements have not been met, 
the ENQ routine processes as follows. If 
the requester is not a system routine, it 
Sets up an error code (338) and invokes the 
ABEND routine to abnormally terminate the 
requester's task. If the RET operand is 
TEST, or if the SMC operand has not been 
specified, the ENQ routine bypasses "set 
must complete" processing. If the current 
SVRB is in a wait condition, meaning that 
the requested resource is not available, 
the ENQ routine temporarily bypasses "set 
must complete" processing. Later, however, 
before exiting, the ENQ routine points the 
SVRB old PSW to a restart point in the "set 
must complete" coding. When the reques- 
ter's task is redispatched, after the 
resource becomes available, the restarted 



ENQ routine will set the requester's task 
in "must complete" status. 

Detecting Abnormal Conditions ; The detec- 
tion of abnormal conditions consists of 
checking the validity of input addresses, 
and checking for duplicate requests issued 
for the same task. 

Checking the Validity of Input Addresses ; 
The ENQ routine checks the validity of 
input parameters supplied by the caller. 
The parameters are a list of main storage 
addresses that point to names of resources 
or sets of resources. The check is 
designed to prevent a program check during 
later processing when the resource queues 
are being updated. The queues might be 
seriously disrupted, thus interfering with 
the performance of other tasks. 

The ENQ routine must first determine if 
it is necessary to check the validity of 
the input parameters. If the caller is a 
system routine, as indicated by a zero pro- 
tection key in the caller's KB old PSW, the 
assumption is that the input parameters are 
valid. In this case, the ENQ routine 
bypasses a validity check of the input 
parameter list. But if entry is from a 
user program, indicated by a nonzero pro- 
tection key in the RB old PSW, the ENQ rou- 
tine uses the supervisor's Validity Check 
routine to test the attributes of each 
input address. (For details see "Testing 
the Validity of User-Supplied Addresses.") 
If any one of the tests fails, indicating 
that the caller has incorrectly specified 
the address of a resource, the ENQ routine 
sets an error code (438) and issues an 
ABEND macro instruction. The ABEND macro 
instruction causes supervisor linkage to 
the ABEND routine to abnormally terminate 
the caller's task. Thus, the cause of the 
abnormal termination is pinpointed, avoid- 
ing the chance of a later program check 
during queue manipulation. 

Checking for Duplicate Requests Issued for 
the Same Task ; The ENQ routine determines 
if the caller, or another routine within 
the same task, has previously requested the 
same resource and has not dequeued the 
request from the queue. If the ENQ routine 
finds QCBs on the queues containing the 
same resource names as those requested by 
the caller and an associated QEL containing 
the caller's TCB address, the caller has 
made a program error. According to the RET 
option that the caller has specified, the 
caller's task is abnormally terminated, or 
the caller is given control with a return 
code indicating that the requested resource 
is already enqueued for the caller's task. 
If the RET option is NONE, or has been 
omitted, the ENQ routine sets up an error 
code (138), and by issuing the ABEND macro 
instruction, causes supervisor linkage to 
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the ABEND routine to abnormally terminate 
the caller's task. If the RET option is 
CHNG, an error condition does not exist 
since the caller must be enqueued for the 
resource if he is requesting a change in 
attribute. If the RET option is neither 
NONE nor CHNG, the ENQ routine sets up a 
return code (8) that indicates that the 
desired resource is already enqueued for 
the caller's task, and after processing 
other parameter- list elements, returns con- 
trol to the caller. The caller can then 
optionally gain access to its requested 
resource. 

Purging Recpiests Previously Enqueued for an 
Abnormally Terminating Task ; If the 
requested resource is already enqueued, and 
if the caller's task is being abnormally 
terminated, the ENQ routine performs a spe- 
cial service for the ninth load module of 
the ABEND routine. It allows the ABEND 
routine to gain access to the abnormal dump 
data set, SYSABEND (or SYSUDUMP) . 

If the caller is the ABEND routine, it 
has issued an ENQ macro instruction to gain 
exclusive use of the dump data set, on 
which the terminated task's resources will 
be dumped. But the data set may already be 
enqueued for a subtask of the caller' s 
task. The subtask may have been set in 
abnormal wait state (nondispatchable) , as 
part of a higher level termination, before 
a DEQ macro instruction could be issued and 
the data set dequeued. In this case, the 
data set may be needlessly unavailable. 

The ENQ routine, via its Autopurge sub- 
routine, makes available the dump data set 
by releasing the QELs that represent pre- 
vious requests for its use. It does this 
by removing from the resource queues all 
QELs belonging to the current task and its 
subtasks. The current ENQ request for the 
dump data set can then be serviced. (For 
information on the need for enqueuing the 
dump data set, refer to "Processing During 
ABEND9" in the chapter entitled "Termina- 
tion Procedures.") 

Increasing the Nonrolloutable Count ; The 
ENQ routine increases by a count of one the 
"nonrolloutable count" (TCBNROC) in the 
caller's job step TCB. It does this for 
each resource for which the ENQ macro 
instruction is issued. To increase the 
count, the ENQ routine invokes the Set Sta- 
tus routine (IGC079) , via the STATUS macro 
instruction. The "nonrolloutable count," 
when greater than zero, makes the job step 
ineligible to be rolled out. 



PROCESSING IN SYSTEMS WITH SHARED DASD ; 
When the shared DASD feature is included in 
the system, the ENQ routine performs device 
reservation functions in addition to its 



normal functions. This section describes 
the device reservation functions. 

The RESERVE macro instruction must spec- 
ify a valid UCB address for a shared direct 
access device. The ENQ routine checks the 
DCB address, and if it is not valid issues 
an ABEND macro instruction. This test fol- 
lows the verification of input addresses 
that is a normal part of ENQ processing. 

The QEL initialization function of the 
ENQ routine is expanded for a reserve re- 
quest. When control of the requested 
resource can be assigned to a task, the ENQ 
routine places the UCB address in the QEL 
and sets the QEL reserve flag. The reser- 
vecount in the specified UCB is then incre- 
mented by one. 

The requested resource cannot be 
assigned to perform a new task when the 
following conditions occur: 

• Resource is in use. 

• Previous QEL on the queue is exclusive, 
or the present request is exclusive. 

• RET operand of the RESERVE macro 
instruction specifies HAVE, NONE, or is 
omitted. 

Under these conditions, the ENQ routine 
prepares for a task switch. It increments 
the SVRB wait count by one, thus placing 
the task for which the resource was 
requested in a wait condition. The ENQ 
routine places the address of the SVRB in 
the QEL for subsequent use by the DEQ rou- 
tine. The need for a task switch is indi- 
cated and control is given to the 
Dispatcher. 

When the requested resource becomes 
available because it is no longer needed in 
the performance of another task, the DEQ 
routine will remove the top QEL and deter- 
mine whether the task associated with the 
new top QEL should be made ready. If it 
should, the DEQ routine decrements the wait 
count in the SVRB whose address is in the 
new top QEL. When the wait count becomes 
zero, the waiting task can be dispatched; 
the ENQ routine then regains control. The 
"reserve restart" subroutine of the ENQ 
routine inserts the UCB address in the QEL, 
sets the reserve flag, and increments the 
reserve count in the UCB by one. 

Signaling that the Use of One or More 
Resources is Complete 

When a program that previously issued an 
ENQ macro instruction (or, in systems which 
include the shared DASD feature, a program 
which issued a RESERVE macro instruction) 
and has been using an enqueued resource 
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completes its use, it issues a DEQ macro 
instruction. The DEQ macro instruction, 
via an SVC interruption (SVC 48) , obtains 
supervisor-assisted linkage to the DEQ rou- 
tine- This routine removes one or more 
QELs, a minor QCB, or a major QCB from the 
resource queues. It also reduces the RB 
wait count for the waiting program whose 
QELs are at the top of one or more QEL 
queues . If the RB wait count becomes zero , 
thus making ready the waiting program, the 
DEQ routine invokes the Task Switching rou- 
tine. The Task Switching routine tests the 
need for a possible task switch, and 
branches to the Exit routine and the Dis- 
patcher to return control. The program 
that receives control is either the caller 
or the previously waiting program, depend- 
ing on relative task priority. An addi- 
tional function of the DEQ routine, used 
only by a supervisor routine, is to reset a 
task in "must complete" status, set pre- 
viously by an ENQ macro instruction issued 
by the caller. 



MAJOR FUNCTIONS: 



When the use of one or 



more resources is signaled complete, via 
the DEQ macro instruction, the major func- 
tions are: 

• Updating the resource queues by dequeu- 
ing and freeing the queue element (QEL) 
that represents the request for the 
resource whose use is now complete. If 
there are no more requests for the 
resource, one or more queue control 
blocks (QCBs) that represent the 
resource are dequeued and their space 
is freed. 

• For the next requester represented on 
the QEL queue, reduction of the wait 
count in its SVRB, and testing if the 
requester is ready to resume execution. 

• Determining if a readied requester can 
replace the caller as the next-to-be- 
executed routine. This involves a com- 
parison of TCB dispatching priorities 
by the Task Switching routine. 

• Returning control to the caller if no 
readied requester's task is of higher 
priority than the caller's. If a 
readied requester's task is of higher 
priority than the caller's, control is 
returned to the requester instead of to 
the caller. 

Updating the Resource Queues : To update 
the resource queues, the DEQ routine 
searches for the QEL that represents a re- 
quest that should now be dequeued. It 
first finds both a major QCB and a minor 
QCB containing the specified resource 
names. The routine then examines the QEL 
queue associated with the specified 
resource. If the caller's TCB address 



matches that stored in one of the QELs log- 
ically at the top of its queue, the DEQ 
routine dequeues the QEL and, via supervi- 
sor linkage to the FREEMAIN routine, frees 
the space that the QEL occupies. 

The DEQ routine examines the QCB queues 
to determine if any QCB may be released. 
If there are no more QELs queued to the 
minor QCB for the resource, there are no 
further requests for the resource, and the 
minor QCB can be released. In this case, 
the routine dequeues the minor QCB from its 
queue and frees the space that it occupies. 
It then examines the minor QCB queue to 
decide whether the major QCB is no longer 
needed and can be similarly eliminated. If 
there are no minor QCBs queued to the major 
QCB, there are no outstanding requests for 
the entire set of resources. In this case, 
the DEQ routine removes the major QCB from 
its queue and frees its space. The routine 
then processes in a similar manner any 
other input parameters which represent QELs 
to be dequeued. 



DeteiTnininq if the Next Waiting Requester 
Should be Readied : After the old top QEL 
is dequeued, the DEQ routine determines if 
the next waiting requester, represented by 
the new top QEL, should be readied. The 
decision is based on the type of new top 
QEL, shared or exclusive, and on the type 
of dequeued QEL. According to the result 
of the decision, the SVRB wait count for 
the waiting requester may or may not be 
reduced and tested for readiness (zero wait 
count) . The criteria and results for three 
different situations are described in 
Figure 3-11. 

If the new top QEL is associated with a 
time sharing task that is not in main 
storage (swapped-out) , a TSEVENT macro 
instruction with the USERRDY operand is 
issued to indicate to the time sharing 
driver that the time sharing task is to be 
brought into main storage ( swapped- in) . 

Determining if a Readied Requester Should 
Be Dispatched : For each SVRB whose awaited 
resources are available, as indicated by a 
zero RB wait count, the DEQ routine tests 
whether the associated requester can be 
dispatched. If the requester's task is of 
higher dispatching priority than the call- 
er's, the requester may be dispatched in 
place of the caller. For each SVRB that 
has a zero wait count, the DEQ routine 
invokes the supervisor's Task Switching 
routine to compare dispatching priorities. 
If the readied requester's TCB has a higher 
priority than the caller's, the Task 
Switching routine indicates this fact to 
the Dispatcher by placing the requester's 
TCB address in the "new" TCB pointer, 
lEATCBP . 
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j Conditions 
Condition A 
dequeued QEL 
new top QEL 



-T- 
I 



Status of QEL Queue j 



Resultant Processing 



l~ 



" shared" QEL 
"shared" QEL 



Condition B 
dequeued QEL 
new top QEL 



QEL of either type 
"exclusive" QEL 



Routine does not reduce 
wait count in recpiester's 
RB. (Requester already 
has access to the resource.) 



Routine reduces wait count 
in requester's RB and if 
new wait count is zero, it 
invokes the Task Switching 
routine to test vrtiether the 
requester may be dispatched 
instead of the caller. 



Condition C 



dequeued QEL 
new top QEL 



"exclusive" QEL 
"shared" QEL 



Routine reduces wait count 
in requester's RB and if 
new wait count is zero, it 
invokes the Task Switching 
routine. Since new top QEL 
is the first QEL of a 
"shared" group, the routine 
repeats this procedure for 
the other QELs of the 
group. 



Figure 3-11. Determining if the Next Waiting Requester Should be Readied 



Returning Control ; The DEQ routine returns 
control to the caller or a readied request- 
er, via the Exit routine and the Dispatch- 
er. The Exit routine dequeues the SVRb 
from its RB queue and frees the space that 
the SVRB occupies. The Dispatcher decides 
whether to return control to the caller or 
to a readied requester, depending on the 
contents of the "new" TCB pointer, lEATCBP. 
If the "new" TCB pointer contains the 
address of the current TCB, the Dispatcher 
returns control to the caller. Otherwise, 
the Dispatcher returns control to the requ- 
ester whose TCB address is in the pointer. 
In this case a task switch has occurred. 



MINOR FUNCTIONS ; When the use of one or 
more resources is signaled complete, via a 
DEQ macro instruction, the minor functions 
are: 

• If the "reset must complete" parameter 
is present, the clearing of the "must 
complete" status of the caller's task. 



• Checking the validity of input address- 
es. 

• Checking if a specified resource was 
originally requested for any task. 

• Checking if the caller has access to a 
specified resource. 

• Reducing the "enqueue count" in the 
caller's TCB. The enqueue count is 
tested during normal task termination 
by the EOT routine to determine if all 
resource requests for the task have 
been dequeued. (See "Termination Pro- 
cedures.") 

• Decreasing by a count of one the "non- 
rolloutable count" (TCBNROC) in the 
caller's job step TCB. 

The Clearing of "Must complete" Task Sta- 
tus ; If the "reset must complete" parame- 
ter has been specified, the DEQ routine 
restores multitask operation to the job 
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step or system, which temporarily had been 
performing only the caller's task. This 
restoration is done only if the caller is a 
system routine (uses zero protection key) . 
If the caller is not a system routine, the 
DEQ routine sets up an error code (330) and 
invokes the ABEND routine to abnormally 
terminate the caller's task. 

If "reset must complete" processing has 
been performed during DEQ, a TSEVENT macro 
instruction with the RELMC operand is 
issued to indicate to the time sharing 
driver that this processing has been 
performed. 

The DEQ routine clears the "must com- 
plete" nondispatchability flag (see Figure 
3-10) in each TCB of the job step or sys- 
tem, depending on the scope. This action 
allows the Dispatcher to restart routines 
for previously nondispatchable tasks. The 
DEQ routine also clears two flags in the 
caller's TCB. One flag, wlien cleared,, 
allows the Stage 3 Exit Effector to resume 
the schedtiling of user exit routines for 
the caller's task. The other flag, when 
cleared, permits the ABEND routine to 
abnormally terminate the caller's task, if 
the need arises, instead of placing the CPU 
in a disabled wait state (see Figure 3-10). 
To clear the "must complete" status, the 
DEQ routine invokes the Set Status routine 
(IGC079), via the STATUS macro instruction. 

Checking the Validity of User-Supplied Ad- 
dresses ; The DEQ routine must check the 
validity of a list of main storage address- 
es supplied by a user program. The ad- 
dresses point to names of resources or sets 



of resources. But if entry is from a sys- 
tem routine, the assumption is that the 
input parameters are valid, and no validity 
check is made. 

If entry is from a user program, as 
indicated by a nonzero protection key in 
the caller's RB old PSW, the DEQ routine 
checks input parameters via the supervi- 
sor's Validity Check routine. The Validity 
Check routine tests the typical three 
attributes of each input address. (For 
details, see "Testing the Validity of User- 
Supplied Addresses.") If any of the validi- 
ty checks fails, indicating that the caller 
has incorrectly specified the address of a 
resource, the DEQ routine sets an error 
code (430) and issues an ABEND macro 
instruction. The ABEND macro instruction 
causes supervisor-assisted linkage to the 
ABEND routine to abnormally terminate the 
caller's task. 

Determining if a Specified Resource Was 
Originally Recpiested for Any Task ; If the 
input parameters are valid, the DEQ routine 
searches the QCB queues to determine if the 
specified resource was originally requested 
for any task. The resource may be dequeued 
only if it was previously enqueued. If the 
resource was enqueued, the resource names 
are represented on the QCB queues, con- 
tained in a major and a minor QCB. But if 
the two QCBs representing the resource can- 
not be found, a DEQ macro instruction has 
been issued for a resource that was not 
enqueued, or which has already been 
dequeued. The DEQ routine recognizes an 
error condition and reacts according to the 
RET option, as shown in Figure 3-12. 



I 

Resource names are not found in the 
QCB queues, or a QEL containing the 
caller's TCB address is not found. 



Condition 



T T 

RET Operand of 
DEQ Macro 
Instruction Is 



Resultant Processing 



H 



HAVE 



omitted 
or NONE 



h 



QEL containing caller's TCB address 
is found, but is not at the logical 
top of the QEL queue, nor is it one 
of a "shared" group of QELs at the 
logical top of the queue. 



HAVE 



h 



omitted 
or NONE 



(1) Sets up return code of 8, in- 
dicating that the resource is not 
enqueued, and after processing 
other parameter-list elements, 
returns control to the caller, via 
the Exit routine and the Dispatcher 



(2) Sets up an error code of 130 
and obtains supervisor linkage to 
the ABEND routine to abnormally 
terminate the caller's task 



H 



Same as (1) but return code is 4, 
indicating that the caller's task 
does not have access to the 
resource. 



-H 



Same as (2) except that the error 
code is 230. 



Figure 3-12. Error Conditions when Use of a Resource is Signaled Complete 
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Determining if the Caller Has Access to a 
Specified Resource ; The caller can right- 
fully dequeue a resource only if it has 
access to it. To determine if the caller 
has such access, the DEQ routine examines 
the QEL queue associated with the resource. 
The QEL containing the caller's TCB address 
should be at the logical top of the queue, 
or be one of a "shared" group of QELs at 
the logical top of the queue. If neither 
condition exists, the DEQ routine recog- 
nizes an error condition, as shown in 
Figure 3-12. 

Decreasing the "Nonrolloutable count" ; The 
DEQ routine decreases by a count of one the 
"nonrolloutable count" (TCBNROC) in the 
caller's job-step TCB. It does this for 
each resource for which a DEQ macro 
instruction is issued by a routine of the 
job step. To decrease the count, the DEQ 
routine invokes the Set Status routine 
(IGC079) , via the STATUS macro instruction. 
When the "nonrolloutable count" is zero, 
the job step is eligible to be rolled out 
to satisfy an unconditional storage request 
from a job step of another job. 

PROCESSING IN SYSTEMS WITH SHARED DASD ; 
When the shared DASD feature is included in 
the system, the DEQ routine performs device 
release functions in addition to its normal 
functions. This section describes the 
device release functions. 



A release request (a DEQ macro instruc- 
tion associated with a RESERVE macro 
instruction) is indicated when the reserve 
flag in the QEL is set. The DEQ routine 
decrements by one the reserve count in the 
UCB whose address is in the QEL; if this 
reduces the count to zero, the associated 
direct access device must be released. The 
EXCP Interface subroutine of the DEQ rou- 
tine issues a GETMAIN macro instruction to 
obtain space for the control blocks 
required for the EXCP macro. When all con- 
trol blocks (lOB, DCB, ECB, DEB, CCW, AVT) 
have been initialized, the EXCP Interface 
subroutine issues an EXCP macro, followed 
by a WAIT macro instruction. 



The effect of the execution of the EXCP 
Interface subroutine is that I/O activity 
is initiated at the specified direct access 
device. Because the reserve count was 
reduced to zero before the I/O activity 
started, lOS will physically release the 
device. 



When the WAIT macro instruction has been 
satisfied, the EXCP Interface subroutine 
regains control to remove the control 
blocks it initialized. Normal DEQ process- 
ing then resumes . 



The ABEND13 routine must also terminate 
device reservations acquired through the 
RESERVE macro instruction and not released 
through a stibsequent DEQ macro instruction. 
These device reservations occur only in 
systems with the shared DASD option. 

Outstanding reservations are reflected 
in the TCB enqueue count (offset 112 in the 
TCB) ; the enqueue count indicates the num- 
ber of outstanding ENQ requests (that is, 
it is not directly related to outstanding 
reservations). When the enqueue count is 
not zero, the ABEND13 routine branches to 
the ENQ/DEQ Purge subroutine in the ENQ/DEQ 
module. If shared DASD is included in the 
system, this routine determines whether the 
terminating task has outstanding device 
reservations. The QEL indicates whether it 
was created as a result of a RESERVE or an 
ENQ macro instruction. If the result of 
RESERVE, the device is released. 



SCHEDULING A USER EXIT ROUTINE 

A user program may request the future 
execution of its exit routine to handle an 
unpredictable event, such as an end-of-task 
condition, expiration of a timer interval, 
or special I/O handling (for example, tape 
label checking or I/O error checking). The 
scheduling of user exit routines (sometimes 
called asynchronous exit routines) is han- 
dled by several supervisor routines: the 
Stage 1 Exit Effector, the Stage 2 Exit 
Effector, the Stage 3 Exit Effector, and 
the Exit routine. Note that these routines 
do not schedule the execution of user pro- 
gram check routines. ABEND processing that 
results from a program interruption can be 
intercepted by a SPIE macro instruction or, 
in the absence of SPIE, by a STAE macro 
instruction. See "Specifying a Program 
Interruption Exit Routine" for a descrip- 
tion of the SPIE routine. See "Specifying 
a Task Asynchronous Exit Routine" in Sec- 
tion 10 for a description of the STAE 
routine. 

As shown in Figure 3-13, the handling of 
a request for the future execution of a 
user exit routine is a multipart procedure, 
interwoven with the execution of programs 
executed for other tasks. The procedure 
begins when the user program originally 
issues a request for an exit routine. The 
user program makes the request via operands 
in such macro instructions as ATTACH (ETXR 
operand), STIMER, and DCB. A system rou- 
tine (for example, the Attach routine) then 
issues a special system macro instruction 
(CIRB) . The CIRB macro instruction causes 
the Stage 1 Exit Effector to construct an 
interruption request block (IRB) to handle 
future scheduling of the user exit routine. 
In addition, the system routine constructs 
an interruption queue element (IQE) , which 
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User program requests, via macro-instruction, 
the use of an exit routine (e.g. , STIMER or 
ATTACH) . 



System routine constructs queue element 
(IQE), if needed, and if interruption request 
block (IRB) does not already exist, issues 
CIRB macro-instruction to create IRB. 



Execution of 
>- Programs for 
Task A 



SVC Interruption 



Exit Effector, Stage 1 



Constructs an IRB to be later used in 
scheduling the execution of the user exit 
routine 



[ Occurrence of the event 
L^'^requiring the user exit 
/ routine (e.g., expiratior 
'"^ of preset timer interval 
I or an end-of-task) 



Execution of 
>"Supervisor 
Routine 



Execution of 
Programs In 
System, Based 
on Task Priority 



Exit Effector, Stage 2 



Performs initial scheduling of user exit 
routine by placing the queue element (IQE) 
on its appropriate exit queue. 



X 



Dispatcher 



Recognizes that stage 2 has placed a queue 
element on one of the exit queues. Passes 
control to stage 3. 



Execution of 
>-Supervisor 
Routines 



Exit Effector, Stage 3 



Completes scheduling of user exit routine 
by transferring the queue element 
(representing request for the routine) from 
an exit queue to a queue whose list origin 
is the IRB for the routine. Places IRB on 
the RB queue belonging to the requestor's 
TCB. 



^ 



^ 



Dispatcher 



Returns control to a program belonging to a 
task other than task A 



_L 



Dispatcher 



Gives control to the user exit routine 
requested for task A 



User Exit Routine 



Exit Routine 



Removes top queue element from IRB's queue 
and returns it to available list of queue 
elements (If queue element is RQE, the 
transfer to available list is done by the I/O 
Supervisor; If queue element is an IQE for 
roll out/roll in, the transfer to the available 
list is done by the roll out/roll in module.) 
If there is another element on IRB's queue, 
prepares for later rescheduling of IRB on 
RB queue of another TCB. If there are no 
more queue elements on the IRB's queue, 
removes IRB from its task's RB queue. If 
IRB v/as dynamically acquired, frees 
storage occupied by the IRB. 



A. 



Dispatcher 



Either passes control to an exit routine 
requested for another task or returns control 
to the current program of task A or another 
ready task. 



Execution of 
Programs In 
System, Based 
on Task Priority 
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Executfon of 
VSupervisor 
RouHne 



Execution of 
I User Exit 
[Routine for 
J Task A 



Execution of 
S-Supervisor 
Routines 



Figure 3-13. Scheduling of Asynchronous Exit Routines 



Stages 2 and 3 of the Exit Effector and the 
Exit routine later manipulate to schedule 
the execution of the user exit routine. 
Data management routines, however, do not 
construct IQEs, since I/O queue elements 
already exist. These elements are called 
request queue elements (RQEs) and are made 
available by the I/O Supervisor. 

After the Stage 1 Exit Effector con- 
structs the IRB to represent the user rou- 
tine, no scheduling occurs until the unpre- 
dictable event takes place that requires 
the exit routine. The Stage 2 Exit Effec- 
tor, a supervisor subroutine, performs ini- 



tial scheduling of the user exit routine by 
placing the previously constructed queue 
element, an IQE or RQE, on its appropriate 
exit queue. There are two such queues 
whose elements represent requests to use a 
particular exit routine. One queue con- 
tains IQEs and represents requests to use a 
routine such as a timer exit routine or an 
end-of-task routine. The other queue 
represents requests for data management 
exits and contains only RQEs. These RQEs 
are the same elements that the I/O Supervi- 
sor uses to schedule I/O requests. Both 
exit queues operate in first-in, first-out 
order, with no regard to the task priority 
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of each program requesting the same exit 
routine. When an element is placed on 
either exit queue, the IRB that represents 
an exit routine is not yet on a task's RB 
queue and cannot yet be executed. The 
placing of a queue element on an exit queue 
by the Stage 2 Exit Effector is therefore 
only a "bookkeeping" manipulation. 

The Stage 3 Exit Effector completes the 
scheduling of the user exit routine. Stage 
3, a subroutine of the Dispatcher, removes 
queue elements from either of the two exit 
queues and places them on another queue 
whose list origin is the IRB representing 
the exit routine. The transferred queue 
elements are thus queued for a specific 
exit routine. Stage 3 completes the sched- 
uling of the user exit routine by placing 
the IRB on the RB queue of the requesting 
program's task. The exit routine, so 
scheduled, can compete for CPU time with 
programs being executed for other tasks. 
When the requesting program's TCB, which 
points to the IRB, has highest priority 
among the ready TCBs, the Dispatcher loads 
the IRB's old PSW to place the user exit 
routine in execution. 

When the user exit routine is complete, 
it invokes supervisor-assisted linkage to 
the supervisor Exit routine. The supervi- 
sor Exit routine removes the top queue ele- 
ment from the IRB's queue of request ele- 
ments. The removed element represents the 
satisfied request for the user exit 
routine. 

After removal from the IRB's queue, the 
queue element is returned to a free list. 
If there are more elements on the IRB's 
queue, representing other requests for the 
routine, the Exit routine prepares for 
later rescheduling of the IRB on the RB 
queue of a different task. If there are no 
more (jueue elements on the IRB's exit 
queue, the Exit routine dequeues the IRB 
from the TCB's RB queue and, if the IRB is 
dynamic and not a system RB, frees the 
storage occupied by the IRB. Thus, the 
scheduling process, which began with the 
construction of an IRB at macro- execution 
time, ends with the possible release of the 
IRB after the user exit routine is 
complete. 

The Stage 1 Exit Effector (CIRB Routine) 

The Stage 1 Exit Effector is a resident, 
disabled, reenterable SVC routine that may 
be called by a supervisor routine, such as 
the Attach routine, or by a data management 
routine. Its purpose is to create and 
initialize, according to input parameters, 
an interruption request block or IRB to 
control a user exit routine whose future 
use is requested by the caller. The rou- 
tine obtains a work area, in which the 



caller may construct interruption queue 
elements (IQEs), and optionally a 72-byte 
register save area in which the user exit 
routine may later save the registers of the 
requesting program. The Attach SVC rou- 
tine, when it is executed, uses the work 
area to construct both the new TCB for the 
subtask and the IQE for the ETXR or end-of- 
task exit routine. The Stage 1 Exit Effec- 
tor obtains space for the IRB and the work 
area, if requested, from supervisor queue 
space, subpool 253. The work area follows 
and is immediately contiguous to the IRB. 
The register save area, if requested, is 
obtained from subpool zero of the user pro- 
gram's region of storage, and is therefore 
not contiguous to the IRB and its work 
area. After obtaining the needed storage 
for the IRB and optional work and save 
areas, the Stage 1 Exit Effector initial- 
izes the IRB, as shown in Section 12. The 
initialization is done according to flag 
bits passed to the routine in register 1. 
The information placed in the IRB during 
the initialization includes the save area 
address, the size of the IRB, the entry- 
point address of the user exit routine, and 
the PSW to be loaded to start execution of 
the user exit routine. When the stage 1 
Exit Effector completes the initialization 
of the IRB, it returns control to the cal- 
ling program via the supervisor Exit rou- 
tine and the Dispatcher. 



The stage 2 Exit Effector 

When Stage 2 is entered. Stage 1 has 
already created and initialized the IRB, 
and the requesting system routine has 
created and initialized the IQE. Stage 2 
is entered as a subroutine by any supervi- 
sor routine wishing to schedule a user exit 
routine. Two typical callers are the 
supervisor EOT routine, during end-of-task 
processing, and the Timer Second- Level 
Interruption Handler, when a preset timer 
interval has expired. Stage 2 places the 
input queue element, whose address is 
passed in register 1, onto either of two 
exit queues. The queue element is queued 
at the bottom of the appropriate queue. If 
the input address appears in true form (a 
positive address). Stage 2 places the queue 
element on the queue of RQEs, (called AEQA) 
used for scheduling data management exits. 
If, however, the input address is in com- 
plement form. Stage 2 interprets the input 
queue element as an IQE and places it at 
the end of the IQE list (AEQJ) , whose ele- 
ments are used to schedule non- data- 
management exits. (See Section 12, "Con- 
trol Blocks and Tables" for the format and 
content of IQEs and RQEs.) Stage 2 then 
sets a Stage-3 switch (lEAODSOl), which the 
Dispatcher will test later to determine 
whether to call Stage 3 to complete the 
scheduling begun by Stage 2. 
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The Stage 3 Exit Effector 

The Stage 3 Exit Effector operates as a 
subroutine of the Dispatcher. Its purpose 
is twofold: to transfer IQEs and RQEs from 
their exit queues to queues belonging to 
particular IRBs (and thus specific to a 
particular user exit routine) , and if pos- 
sible, to place these IRBs on the RB queues 
of the attaching programs' TCBs. As soon 
as an IRB is on an RB queue, the exit rou- 
tine represented by the IRB may (if task 
priority permits) be placed in execution by 
the Dispatcher. An additional function of 
Stage 3 is to schedule a request (RQE) for 
an I/O error routine by placing its system 
interruption request block (SIRB) on a spe- 
cial high-priority system TCB. 



Stage 3 is entered from the Dispatcher 
if the Stage- 3 switch (lEAODSOl) has been 
set by Stage 2, indicating that at least 
one IQE or RQE is on an exit queue. (There 
are two exit queues, one for IQEs, the 
other for RQEs.) stage 3 begins by pro- 
cessing the IQE queue. If there are no 
elements on the IQE queue, the routine then 
processes the RQE queue. 



If there is at least one IQE, Stage 3 
performs some tests to determine if each 
IQE on the queue may be removed from the 
exit queue and placed on a queue belonging 
to an IRB (which represents a particular 
user exit routine) . If any of the tests 
indicates that an IQE should not be trans- 
ferred to an IRB queue. Stage 3 obtains the 
next IQE on the list and repeats the tests. 
One of the tests asks whether the IQE' s 
intended IRB is "active." (The IQE con- 
tains a pointer to its "intended" IRB. 
(See Section 12, "Control Blocks and 
Tables.") An IRB is considered "active" if 
the IRB is already queued to a TCB. This 
condition is indicated by the RBFACTV bit 
in the RBSTAB field of the IRB. If the 
IQE' s intended IRB is already queued to a 
TCB, that is, is "active", the routine then 
tests if the same TCB is specified by this 
IQE. (The IQE contains a pointer to the 
TCB for the task that needs the user exit 
routine.) In other words, this test asks 
whether the IRB that is already scheduled 
(queued) is the intended IRB for this IQE. 
If the IRB is queued to the correct TCB, or 
if the IRB is inactive (not queued to any 
TCB) , Stage 3 removes the IQE from its exit 
queue and queues it to the bottom of the 
IRB's queue. (The list origin for the 
IRB' s IQE queue is in the IRB and is called 
the RBIQE field. See Section 12.) After 
placing the IQE on the IRB's list of queue 
elements. Stage 3 proceeds to initialize 
the IRB as follows, in preparation for 
entry to the user (asynchronous) exit 
routine. 



If the IRB is not already on the RB 
queue of a TCB (as indicated by the pre- 
vious test of the RBFACTV bit in the IRB 
status field) , the routine places the IRB 
on the appropriate task's RB queue. The 
TCB then points to this IRB as the current 
RB representing the routine next to be 
executed for this task. Stage 3 then saves 
register contents stored in the TCB (that 
could later be overlaid and thus lost) by 
moving the contents to the register save 
area of the IRB. It initializes the PSW 
and standard register settings for the user 
exit routine. Then, to determine if the 
newly queued IRB's task is of higher 
priority than the current task. Stage 3 
invokes the Task Switching routine to test 
if a task switch is needed. If a task 
switch is needed, the Task Switching rou- 
tine indicates this need to the Dispatcher. 
It does this by placing the address of the 
higher priority TCB in the "new" TCB point- 
er (lEATCBP). The address of the "new" TCB 
pointer is contained in the CVT at location 
CVTTCBP. 



If there are one or more IQEs remaining 
unprocessed on the IQE exit queue. Stage 3 
processes these IQEs in a manner similar to 
that just described. 



When all elements on the IQE queue have 
been processed. Stage 3 processes the queue 
of RQEs in a similar fashion. The reader 
may recall that the RQEs, supplied by the 
I/O Supervisor, are used to schedule I/O 
exit routines. One feature of RQE process- 
ing is different from IQE processing, and 
deserves special mention. 

One or more of the RQEs may represent a 
request by an I/O routine for the use of a 
system error handling routine. When Stage 
3 examines each element on the RQE queue, 
it tests if the queue element represents a 
request to use an error routine. The "F" 
bit in each RQE indicates whether the RQE 
represents such a request. (See format of 
an RQE in Section 12.) If one or more RQEs 
represents requests for the use of an error 
routine. Stage 3 perfoirms special process- 
ing for these RQEs. Other RQEs, not repre- 
senting requests for error routines, are 
processed in a manner very simdlar to IQE 
processing. 

For each RQE representing a request to 
use an error routine. Stage 3 tests first 
whether a special system request block is 
"active," that is, already queued to its 
system error TCB. The system error TCB is 
a permanent TCB of high priority whose cur- 
rent "dummy" RB is normally in a wait con- 
dition. The request block that represents 
a system error handling routine is called a 
system interruption request block, or SIRB. 
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If the SIRB is already queued to the 
system error TCB, the "active" bit 
(RBFACTV) is set in the SIRB's status 
field. In this case, the error routine has 
already been scheduled for another request. 
The new request must then be deferred and 
await the next execution of Stage 3, when 
the Dispatcher is next entered. 

If the SIRB is not "active," that is, 
not queued to the system error TCB, stage 3 
clears the I/O error flag or 'F" bit in the 
RQE. It removes the RQE from its asynchro- 
nous exit queue and queues it to the SIRB. 
Stage 3 then initializes the SIRB. As part 
of this initialization, it sets the RB old 
PSW to provide reentry to the "error fetch 
sequence" (ERFETCH) of Stage 3. 

Besides altering the RB old PSW, Stage 3 
queues the SIRB to the system error TCB. 
The error TCB now points directly to the 
SIRB, instead of to its permanent dummy RB. 
When all RQEs on the asynchronous exit 
queue have been processed, the Dispatcher 
will cause reentry to Stage 3 at entry 
point ERFETCH, under control of the system 
error TCB. 

If Stage 3 did not complete the process- 
ing of RQES at the time it discovered a re- 
quest for a system error routine, it now 
completes the processing of other RQEs. 
(If an RQE represents a request for an I/O 
error routine, the 'F' flag appears set in 
the RQE.) After Stage 3 queues the SIRB to 
the system error TCB, it defers subsequent 
error requests on the RQE queue. These 
requests are not processed until the SIRB 
becomes "inactive," removed from its TCB 
during Exit routine processing. 

In MVT with Model 65 multiprocessing, 
the TCB indicated by the IQE or RQE may be 
the current TCB on the second CPU. If it 
is, control is passed to the SHOLDTAP rou- 
tine which interrupts the second CPU with 
an indication that the Dispatcher is to 
gain control on the second CPU and place 
the IRB on the appropriate RB Queue. 

After processing the two lists, IQEs and 
RQEs, Stage 3 returns control to the Dis- 
patcher. The Dispatcher passes control to 
the interrupted program belonging to the 
current task, or to a user exit routine 
belonging to another task, or to the Stage 
3 Exit Effector at entry point ERFETCH to 
begin the loading of an error routine. 

TSO Processing 

If an IQE exists, the stage 3 Exit Effe- 
ctor determines the type of IRB associated 
with it. If the IRB is not an inactive 
attention IRB, processing continues as 
described above. If it is an inactive 
attention IRB, the TCB associated with this 



IRB and all lower tasks in this user's task 
structure are checked to determine whether 
attention exits and asynchronous exits are 
permitted. If not, processing continues as 
described above. If these exits are per- 
mitted, the IQE is scheduled by queueing 
the IQE to the IRB in first- in first-out 
order. 

FETCHING AN ERROR ROUTINE ; ERFETCH is the 
entry point to a so-called "error fetch 
sequence" that performs for error routines 
the function that the Transient Area Fetch 
routine performs for transient SVC rou- 
tines. That is, the "error fetch sequence" 
searches for the desired error routine and, 
if necessary, fetches it to the I/O Super- 
visor transient area. 

The error fetch sequence first compares 
the SIRB name field, which contains the 
name of the previously executed error rou- 
tine, to the name field of the currently 
required error routine. If the names 
match, the error fetch sequence links to 
the previously determined entry point for 
the error routine. 

If the names do not match and if the 
resident error recovery procedure option 
was selected during system generation, the 
name of the required error routine is com- 
pared with the name of the error routine 
last fetched into the I/O supervisor error 
transient area. If these names match, the 
error fetch sequence links to the start of 
the I/O supervisor transient area. If the 
names do not match, the chain of CDEs that 
describe the error routines made resident 
during nucleus initialization is searched. 
If the name field in one of the CDEs on 
this chain matches the name of the required 
error routine, the error fetch sequence 
obtains the entry point address for the 
resident error routine and links to this 
address. 

If the resident error recovery option 
was not selected during system generation 
or if the required error routine is not 
resident, the error fetch sequence invokes 
the BLDL routine to get data set directory 
information in preparation for fetching the 
I/O error module. 

If the BLDL routine encounters a per- 
manent I/O error, the error fetch sequence 
recycles the BLDL operation up to five 
times. The total count of recycles of BLDL 
and FETCH operations (see below) for one 
use of the error fetch sequence cannot 
exceed five. The recycle count is kept in 
the error fetch sequence's work area; it is 
re- initialized after each use of the error 
fetch sequence. If the permanent I/O error 
persists after five recycles of the BLDL 
operation, the error fetch sequence passes 
control to the Dynamic Device Reconf igura- 
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tion SYSRES Effector, if DDR SYSRES support 
is in the system. DDR SYSRES returns con- 
trol to the error fetch sequence with a 
return code of or 4. If the return code 
is 0, the BLDL operation is recycled again 
once. If the return code is 4, the error 
fetch sequence sets up an error code (806) 
and branches to the ABTERM routine. If the 
renewed attempt to recycle the BLDL opera- 
tion results in a permanent error, DDR SYS- 
RES is not invoked again. Instead, per- 
manent error processing takes place; the 
error fetch sequence sets up an error code 
(806) and branches to the ABTERM routine. 
The ABTERM routine schedules abnormal ter- 
mination of the task for which the error 
routine was requested. The error fetch 
sequence then returns control to the cur- 
rent routine of the highest priority ready 
task, via the Exit routine and the 
Dispatcher. 

If there is no error during execution of 
the BLDL routine, the error fetch sequence 
branches to the supervisor's Program Fetch 
routine to load the error routine. If no 
error is detected during the fetch process, 
the error fetch sequence links to the entry 
point address of the I/O supervisor tran- 
sient area. If, however, the FETCH routine 
encounters a permanent I/O error, process- 
ing continues as for BLDL (see above) , 
except that the error fetch sequence posts 
a completion code of B06 when control must 
be passed to ABEND. 

The Exit Routine 



routine for another task, the Exit routine 
prepares for future reentry to the exit 
routine and does not remove the RB from its 
TCB. In all cases except the last, the 
Exit routine branches to the Transient Area 
Refresh routine. If the asynchronous exit 
routine must be reentered for another re- 
quest, the Exit routine branches to the 
Dispatcher. 



The above discussion is an overview of 
the Exit routine's role in the scheduling 
of user (asynchronous) exit routines. A 
more detailed description of the same pro- 
cessing follows. 

The Exit routine first determines the 
type of RB under which the caller (RETURN- 
issuing program) is operating. If the type 
is either SIRB or IRB (as indicated by the 
RBFTP bits in the RBSTAB field), the Exit 
routine assumes that the RETURN-issuing 
program, or caller, is a user exit routine. 
If the caller's RB is an SIRB, which means 
that the RETURN-issuing program is a system 
error routine, the Exit routine branches to 
the routine that removes an RB from its TCB 
and tests whether to free the RB' s storage 
space. Since the SIRB is a peinnanent RB, 
its space is not freed. But the SIRB is 
removed from the system error TCB. Since 
there are no further requests for the error 
routine (no RQEs queued to the SIRB) , the 
Exit routine branches to the Dispatcher to 
return control to the current routine of 
another task. 



This discussion of the Exit routine 
includes only that part of its processing 
that affects the scheduling of user (asyn- 
chronous) exit routines, other aspects of 
its processing are described later in the 
topic entitled "Exiting Procedures." 

The Exit routine, among its other func- 
tions, deletes the scheduling performed by 
the three Exit Effectors. The Exit routine 
is given control by the SVC FLIH after a 
user exit routine has issued a RETURN macro 
instruction. For both types of RBs — SIRB 
and IRB — if there are no other requests 
(queue elements) for the user exit routine, 
the Exit routine removes the RB from its 
TCB. If the RB is an IRB, and therefore 
was dynamically acquired by a GETMAIN macro 
instruction, the Exit routine frees the 
storage occupied by the IRB . The top IQE 
or RQE, representing a request for the user 
exit routine, is removed from the IRB' s 
list of queue elements, since the request 
has been satisfied and is no longer needed. 
If there is a list of available unscheduled 
queue elements, the Exit routine returns 
the removed element to the "available" 
list. If, however, another element remains 
on the RB's queue, representing an addi- 
tional request to use the asynchronous exit 



If the caller's RB is an IRB, the 
returning program is a user exit routine 
and not a system error handling routine. 
In this case the Exit routine performs more 
elaborate processing. It first checks the 
type of queue element at the top of the 
IRB's queue to determine if the element is 
an IQE or an RQE. (A queue can contain 
only one type, not both.) The Exit routine 
makes this check by testing the RBSTAB sub- 
field called RBFIQETP, which indicates the 
type of elements queued to the IRB: RQEs 
or IQEs. (Refer to Section 12 for the for- 
mats of this RB field. ) 

If the IRB's queue contains one or more 
RQEs, the Exit routine removes the top RQE 
(no longer needed) and places the RQE on a 
list of available RQEs for use by the I/O 
supervisor. The Exit routine obtains this 
requeuing by branching to an entry point 
(INT025) to a section of the I/O supervisor 
that returns RQEs to an available list for 
future use. The Exit routine then tests 
whether another RQE is on the IRB's queue, 
representing an outstanding request for use 
of the I/O exit routine by a program 
belonging to the same task. If another RQE 
is on the queue, the Exit routine initial- 
izes registers to prepare for future reen- 



Section 3; Task Supervision 67 



try to the user exit routine and branches 
to the Dispatcher. 

If in its test of the RQE queue, the 
Exit routine finds that there are no other 
RQEs on the IRB's queue, it performs pro- 
cessing somewhat similar to that performed 
for an SIRB. The routine transfers the 
contents of the caller's registers from the 
IRB to the TCB's save area and removes the 
IRB from the RB queue belonging to its TCB, 
since there are no further requests for the 
Exit routine and the IRB is no longer 
needed. The Exit routine then tests wheth- 
er the space occupied by the IRB may be 
freed. The test consists of checking the 
RBFDYN bit in the IRB. If the bit shows 
that the IRB was dynamically acquired and 
is not a permanent RB (such as the SIRB) 
the block may be freed. If the IRB was 
dynamically acquired, the Exit routine 
frees its storage area by invoking the 
FREEMAIN routine, and branches to the Tran- 
sient Area Refresh routine. The Dispatcher 
returns control to the current program 
belonging to the user exit routine's task, 
when that task next becomes the highest 
priority ready task. The PSW for this pro- 
gram is contained in the next RB on the 
TCB's RB queue, after the IRB has been 
removed from the RB queue. 

If the previous test of the type of 
queue element on the IRB's queue indicated 
an IQE, a request for a non-I/0 exit rou- 
tine, the Exit routine tests for a zero 
"use count." The use count (stored in the 
25th byte of the IRB) indicates to the Exit 
routine the number of outstanding requests 
to execute the same user exit routine. For 
example, successive ATTACH macro instruc- 
tions issued for a parent task may have 
specified in the ETXR operand the use of 
the same end-of-task routine for different 
subtasks. If the IRB use count is not 
zero, the Exit routine decreases by one the 
use count to indicate the remaining number 
of requests, not yet scheduled, for the 
user exit routine. 

After decreasing the use count, or if 
the use count is already zero (indicating 
no outstanding requests for the user exit 
routine) , the Exit routine removes the top 
IQE from the IRB. This is done because the 
represented request has been serviced. The 
Exit routine then tests whether the user 
program has provided a work area at the end 
of the IRB. It also tests whether the user 
program wants the IQE to be queued on a 
"liext available" list. The IQE may be 
queued in the work area as an "available" 
element for use by the Stage 2 Exit Effec- 
tor in scheduling a new request. 

The Exit routine tests for the existence 
of the work area by determining the size of 
the IRB. A work area exists if the size 



exceeds 93 bytes (12 doublewords, as indi- 
cated by the RESIZE field of the IRB). The 
exit routine then determines whether to 
queue the IQE to the "next available" list 
(RBNEXAV). If the RBFIQETP field is '11', 
it queues the IQE to the "next available" 
list. Otherwise, the routine continues 
processing. 

The Exit routine next tests for another 
IQE on the IRB's queue of IQEs. The pro- 
cessing from this point is similar to that 
for RQEs, previously discussed. 

Finally, after either initializing reg- 
isters for reentry to the user exit rou- 
tine, or removing the IRB and freeing its 
storage, the Exit routine branches to the 
Transient Area Refresh routine. The Tran- 
sient Area Refresh routine determines that 
the exiting routine is not a transient SVC 
routine. It then returns control to the 
Dispatcher. The Dispatcher returns control 
to either the user exit routine or another 
routine. The other routine may be the rou- 
tine that was interrupted by the timer, if 
a timer interruption had occurred; or it 
may be the current routine belonging to 
another task. 



SERVICES INTERNAL TO THE SUPERVISOR 

Supervisor internal services consist of 
testing and indicating the need for a task 
switch, testing the validity of user- 
supplied addresses, and changing the status 
of tasks. In a multiprocessing system, 
additional supervisor internal services 
include determining the relative priority 
of tasks, testing the dispatchability of 
tasks, and initiating an external interrup- 
tion in a second CPU. 



TESTING AND INDICATING THE NEED FOR A TASK 
SWITCH 

The Task Switching routine is one of the 
subroutines used by a number of supervisor 
routines. The routine determines whether a 
newly readied task, v*iich may be of higher 
priority than that of the caller's, should 
be dispatched in place of the caller's 
task. 

The routine is entered if a supervisor 
routine has reduced to zero a program's RB 
wait count, or has cleared a non- 
dispatchability flag in a TCB. For 
example, the Post routine may make ready a 
program that was awaiting the completion of 
an I/O operation, or the DEQ routine may 
make ready a program that was awaiting a 
serially reusable resource. In either 
case, the supervisor routine does not know 
if the readied routine belongs to a task of 
higher priority than that of the caller. 
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and whether it should replace the caller as 
the cvurrently dispatchable program. 

To answer this question, the supervisor 
routine branches to the Task Switching rou- 
tine. The Task Switching routine compares 
the dispatching priority of the readied 
routine's TCB with that of another TCB. 
The other TCB is either the caller's TCB or 
the TCB for another readied routine, if more 
than one routine has just been readied (for 
example, during DEQ processing). According 
to the result of the comparison, the Task 
Switching routine places the address of the 
higher priority TCB in the "new" TCB point- 
er lEATCBP.^ Later the Dispatcher 
references this TCB pointer to determine 
the task and routine it should dispatch. 

A detailed discussion of the operation 
of the Task Switching routine follows. 

Upon branch entry from the calling 
supervisor routine, the Task Switching rou- 
tine compares the dispatching priority of 
the readied routine's TCB, passed as an 
input parameter, with the dispatching 
priority of another TCB. The address of 
the other TCB — either the current TCB or 
the TCB of a recently readied routine — is 
stored in either half of the doubleword TCB 
pointer at location lEATCBP. The address 
stored in the first word, the "new" TCB 
pointer, has two possible values: zero, or 
the address of a TCB for a previously 
readied task. 

If the first word of the TCB pointer 
contains zero, the Task Switching routine 
compares the dispatching priority of the 
current TCB with that of the TCB for the 
newly readied routine. But if the first 
word of the TCB pointer is not zero, the 
routine compares the dispatching priority 
of a previously readied task, whose TCB 
address is in the "new" TCB pointer, with 
the dispatching priority of the TCB for the 
newly readied routine. (In this case, the 
Task Switching routine has been invoked 
more than once after the same interrup- 
tion.) If the priority of the newly 
readied task is higher than that of the 
other, the Task Switching routine stores 
the address of the readied TCB in the "new" 
TCB pointer (lEATCBP) and returns control 
to the invoking routine. Later the Dis- 
patcher dispatches the current routine 
whose TCB address has been placed in the 
"new" TCB pointer. But if the priority of 
the readied (input) TCB is lower than that 
of the other TCB, the Task Switching rou- 
tine does not change the TCB pointer. It 
merely returns control to the calling 



^The address of the "new" TCB pointer is in 
the communications vector table (CVT) at 
location CVTTCBP. 



supervisor routine. In this case, the Dis- 
patcher, when it gains control, dispatches 
the current routine for any of three possi- 
ble ready tasks: the current task, if the 
"new" TCB pointer (lEATCBP) points to the 
current TCB; a previously readied task, if 
a previous use of the Task Switching rou- 
tine has placed the TCB address in lEATCBP; 
or another task found by a scan of the TCB 
queue, if lEATCBP contains zero. 



A special case exists in which the Task 
Switching routine cannot make a comparison 
between TCB priorities. This is the case 
if the two TCBs have the same dispatching 
priority. If the time- slicing feature is 
included in the system, the Task Switching 
routine tests the time-slice bit (TCBFTS) 
in the TCB. If the bit is set, the Task 
Switching routine returns control to the 
calling supervisor routine without changing 
the TCB pointer. In this case, the Task 
Switching routine must search down the TCB 
queue to discover which TCB is at a higher 
relative position on the queue. It begins 
its search with the TCB pointed to by 
lEATCBP or, if this location contains zero, 
with the current TCB. The address of the 
input or newly readied TCB is stored in the 
"new" TCB pointer only if the input TCB is 
not found below the other TCB on the queue. 
Otherwise, the routine does not change the 
TCB pointer. 



In MVT with Model 65 multiprocessing, 
the Task Switching routine also determines 
if the newly readied task should be dis- 
patched in place of the current task on the 
second CPU. 

If the first word of the TCB pointer of 
either CPU contains zeros, zeros are also 
placed in the first word of the second 
CPU's TCB pointer. Later, the Dispatcher 
searches from the top of the TCB queue to 
find the two highest priority ready tasks. 

If the first word of the TCB pointer of 
neither CPU contains zeros, control is 
passed to the Relative Priority routine 
(RELPRIOR) to compare the dispatching 
priorities of the two TCBs whose addresses 
are in the first words of the TCB pointers. 
The TCB with the lower dispatching priority 
is compared with the newly readied TCB. If 
the priority of the newly readied task is 
higher, the address of the readied TCB 
replaces the address of the other TCB in 
the first word of the TCB pointer. 

The Task Switching routine then deter- 
mines if the TCB to be dispatched on the 
executing CPU is the current TCB on the 
second CPU or vice versa. If so, the ad- 
dresses in the first word of each TCB 
pointer are interchanged. 
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The Task Switching routine then returns 
control to the calling supervisor routine. 
Later the Dispatcher decides the program to 
be executed, as described above. 



TESTING THE VALIDITY OF USER- SUPPLIED 
ADDRESSES 

Supervisor routines use the Validity 
Check routine as a subroutine to check main 
storage addresses passed as input parame- 
ters by user programs. The Validity Check 
routine tests the following attributes of 
each input address: fullword boundary 
alignment (optional) , whether the address 
lies within the boundaries of main storage, 
and if the address specified a storage area 
whose storage protection key matches the 
protection key in the TCB of the calling 
main line program. If any of these tests 
fails, the routine informs the invoking 
supervisor routine by altering the condi- 
tion code of the current PSW. Since the 
calling main line program has made a 
serious error, the invoking supervisor rou- 
tine abnormally terminates the current 
task. Thus, the source of programming 
error is indicated at its point of occur- 
rence, avoiding a program check during 
later processing. Such a program check 
might be difficult to diagnose. If it 
occurred during queue manipulation, the 
queues might be seriously disrupted, thus 
interfering with the performance of the 
other tasks. 



CHANGING THE STATUS OF TASKS 

Routines with a protect key of zero can 
use the Set status routine {IGC079) to set 
or reset the status of particular tasks. 
The affected task status can be either the 
"nonrolloutable" status, the "must com- 
plete" status, or the "nondispatchability" 
status . 

The Set Status routine is invoked, via 
supervisor linkage (SVC 79), through use of 
the STATUS macro instruction. The routine 
is entered either from the SVC First-Level 
Interruption Handler, or via a branch from 
a Type-1 SVC routine. (A Type-1 SVC rou- 
tine may not cause an SVC interruption.) 

The Set Status routine sets (or resets) 
the following conditions for a task or a 
group of tasks: 

• " Nonrolloutable" status , so that the 
tasks of the job step are ineligible 
(or eligible) to be rolled out. 

• " Must complete" status , so that other 
tasks of the job step or system are 
made nondis patch able (or dispatchable) 



while the current task is being 
performed. 

• " Nondispatchability" status , so that 
the routines of the tasks cannot (or 
can) be restarted by the Dispatcher. 

Setting or Resetting the Nonrolloutable 
Status 

When entered via the macro instruction 
STATUS SET, NR, the Set Status routine adds 
'one' to the nonrolloutable count (TCBNROC) 
in the job-step TCB. The step TCB is eith- 
er that associated with the specified TCB, 
or that associated with the caller's TCB 
(if 'S' or no TCB address is specified). 
The nonrolloutable count is later tested by 
the rollout/rollin module to determine if 
the job step is eligible to be rolled out. 
A job step is eligible to be rolled out if 
its nonrolloutable count is zero. 

When entered via the macro instruction 
STATUS RESET, NR, the routine subtracts 
'one' from the nonrolloutable count in the 
job-step TCB. (The particular job step is 
defined in the previous paragraph . ) The 
Set Status routine schedules linkage to the 
rollout/rollin module to restart deferred 
rollout requests, if the nonrolloutable 
count becomes zero while there is at least 
one element on the rollout request queue 
(lEAROQUE) . If such scheduling is needed, 
the routine obtains an interruption queue 
element (IQE) , via the GETIQE routine in 
module lEAQPRTO, and branches to the Stage- 
2 Exit Effector to place the IQE on the 
asynchronous exit queue (AEQJ) . 

Setting or Resetting the "Must Complete" 
Status 

When entered via the macro instruction 
STATUS SET, MC, [STEP] [SYSTEM] , the Set 
Status routine sets the caller's task in 
"step" or "system" must complete status. 
(If the RESET operand is specified, the 
"must complete" status that was previously 
set is cleared. ) The routine sets the must 
complete flag in the current TCB, the "pro- 
hibit asynchronous exits" flag in the cur- 
rent TCB, and the step or system must com- 
plete nondispatchability flag in other TCBs 
of the job step or system. (For the names 
and meanings of these flags, see Figure 
3-10 in "Serializing the Use of a 
Resource.") 

In MVT with Model 65 multiprocessing, 
after the caller's task has been set in 
must complete status, control is passed to 
the Task Removal subroutine. The Task 
Removal routine (TESTDSP) determines wheth- 
er the current task on the second CPU has 
been set nondispatchable, and, if it has, 
interrupts the second CPU with an indica- 
tion (in STMASK) that the Dispatcher rou- 
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tine must gain control. If the RESET 
operand is specified, after the must com- 
plete status is cleared, the Set Status 
routine indicates to the Dispatcher that 
the TCB queue must be searched from the top 
to find the two highest priority ready 
TCBs. This is done by setting the "hew" 
TCB pointer (lEATCBP) of both CPOs to zero. 

Setting or Resetting Nondispatchability 

When entered via the macro instruction 
STATUS SET, ND, (STEP] [SYSTEM] [tcbloc- 
addrx] , (nn) , the Set Status routine sets 
the specified nondispatchability flag or 
flags in the specified set of TCBs. (If 
RESET is specified, the specified nondis- 
patchability flag or flags are cleared in 
the specified set of TCBs.) Three sets of 
tasks can be specified: the system, the 
job step, or a specified task and its 
descendants. If SYSTEM is specified, all 
tasks of the system are set nondispatchable 
except the current task and the permanent 
system task.^ If STEP is specified, all 
tasks of the job step are set nondispatch- 
able except the current task and the job- 
step's initiator. If a TCB address 
(tcbloc-addrx) is specified, the task and 
its descendants are set nondispatchable. 

The particular nondispatchability flag 
or flags that are set (or cleared) in each 
TCB depend on the mask bit number (nn) 
specified in the STATUS macro instruction. 
(See Figure 3-lt.) 

In MVT with Model 65 multiprocessing, 
after the nondispatchability flags have 
been set, control is passed to the Task 
Removal (TESTDSP) subroutine which deter- 
mines whether the current task on the 
second CPU has been set nondispatchable. 
If it has, the second CPU is interrupted 
with an indication (in STMASK) that the 
Dispatcher routine should gain control. 

When a user issues a STATUS macro 
instruction with the START or STOP operand, 
the Set Status routine determines if the 
specified subtask of the current task or 
all subtasks of the current task are to be 
modified. When START is specified, the 
stop/start count is decremented in the sub- 
task TCB(s) and the nondispatchability 
flags are cleared if the count is zero. 
When STOP is specified, the stop/start 
count is incremented in the subtask TCB(s) 
and the nondispatchability flags are set. 
Any option other than START or STOP must be 
specified by a caller running with a pro- 



^The permanent system tasks are: the tran- 
sient area fetch tasks, the system error 
task, the rollout/rollin task (if the rol- 
lout feature is present) , the communica- 
tions task, and the master scheduler task. 



tection key of zero. A task is set nondis- 
patchable only if no system routines are 
executing for it as indicated by the TCBATT 
flag. If a system routine is executing for 
the task, the TCBSTPPR flag is set to ind- 
icate that this task should be made nondis- 
patchable when it no longer has a system 
routine executing. 



DETERMINING THE RELATIVE DISPATCHING 
PRIORITIES OF TASKS 

The Relative Priority subroutine (entry 
point RELPRIOR) is used by the Task Switch- 
ing and Dispatcher routines in MVT with 
Model 65 multiprocessing to determine which 
of two TCBs has the higher dispatching 
priority. Condition codes indicate the 
results as follows: 



Code Indication 

They are the same TCB. 

1 Second TCB has higher priority. 

2 First TCB has higher priority. 



If the dispatching priority of both TCBs 
is equal, the RELPRIOR routine searches 
down the TCB queue, starting with the first 
TCB being compared, to determine which TCB 
is at a higher position on the queue. The 
TCB higher on the queue has the higher dis- 
patching priority. 



TESTING THE DISPATCHABILITY OF TASKS 

The Task Removal subroutine (entry point 
TESTDSP) ensures, in MVT with Model 65 mul- 
tiprocessing, that a task which has been 
set nondispatchable by a routine on one CPU 
does not continue to run on the second CPU. 
The address of TESTDSP is contained in the 
multiprocessing CVT. 



The Task Removal routine first deter- 
mines if the TCB whose address is in the 
"old" TCB pointer (IEATCBP+1) for the 
second CPU has been set nondispatchable. 
If it has, the First CPU Signal routine is 
invoked to cause the Dispatcher routine to 
gain control on the second CPU. After the 
Dispatcher on the second CPU has stored the 
status of the "old" TCB, the Task Removal 
routine determines if the "old" TCB for 
this CPU or the "new" TCB for either CPU 
has been set nondispatchable. If so, the 
"new" TCB pointers (lEATCBP) for both CPUs 
are set to zero. This causes the Dispatch- 
er to search from the top of the TCB queue 
to find the two highest ready tasks. 
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INITIATING AN EXTERNAL INTERRUPTION IN A 
SECOND CPU OF THE MODEL 65 MULTIPROCESSING 
SYSTEM 

The First CPU Signal and SHOLDTAP sub- 
routines are used by supervisor routines in 
MVT with Model 65 multiprocessing to cause 
one CPU to externally interrupt the other 
CPU. As a result of the external interrup- 
tion, a routine specified in the word 
STMASK receives control on the interrupted 
CPU (see description of External FLIH rou- 
tine) . The word STMASK is located in the 
PSA, and the bit designating the routine to 
receive control on the interrupted CPU is 
set in STMASK by the calling routine. The 
address of the SHOLDTAP routine is con- 
tained in the multiprocessing CVT. 

The SHOLDTAP routine first tests the 
pending bit, bit in the STMASK byte, to 
determine if the previous external inter- 
ruption has been processed and the bit 



reset to zero by the External FLIH routine. 
If it is set to 1, the interruption has not 
been processed, and control is returned to 
the calling routine. Otherwise, bit is 
set to 1, and a WRITE DIRECT instruction is 
issued. This instruction causes an exter- 
nal interruption in the other CPU. 



The First CPU Signal routine (entry 
point FLASH) is used when the interrupted 
CPU must perform an immediate service for 
the first CPU. After issuing a WRITE 
DIRECT instruction, the First CPU Signal 
routine tests the word STMASK to determine 
if the external interruption has been pro- 
cessed and the immediate service performed. 
(The appropriate bit in STMASK is cleared 
by the External FLIH routine after the ser- 
vice has been performed. ) Control is 
returned to the calling routine only after 
the immediately requested seirvice has been 
performed. 



Mask Bit 
Number 


1 Offset 
jof Flag 
Flag Name 1 in TCB 
L _ i J 


Meaning of Flag | 

,,. , . 1 


1 


TCBNDUMPI 32.0 


r — 1 

This task is nondispatchable while the resources of a task | 
in this job step are being dumped. j 


2 


TCBSER 1 32.1 


This task is nondispatchable while the SERl routine is | 

being executed for this task. j 

1 


3-6 




Reserved. 


1 

1 

1 


7 


1 32.6 


1 
This task is nondispatchable while VARY or QUIESCE process-] 

ing is being performed in a Model 65 Multiprocessing System,] 

1 


8 


TCBONDSPl 32.7 


1 
This task is nondispatchable while the dump data set is | 
being opened for another task in the same job step. j 


9 


TCBFC 1 33.0 


This task is nondispatchable because 
or abnormally terminated. 


it has been normally j 


10 


TCBABWF 1 33.1 


This task is nondispatchable as part 
that is being abnormally terminated. 


of a tree of tasks j 


11 


TCBWFC 1 33.2 


This task is nondispatchable because 
requested storage space. 


it is waiting for j 


12 


TCBFRO 1 33.3 


This task is nondispatchable because 
out job step. 


it is part of a rolled j 


13 


TCBSYS 1 33.4 


This task is nondispatchable while another task in the sys-| 
tem is in "system must complete" status- j 


14 


TCBSTP 1 33.5 


This task is nondispatchable while another task in the samej 
job step is in "step must complete" status. | 


15 


TCBFCDl 1 33.6 


This task is nondispatchable because it is an initiator j 

that is waiting for a requested region of main storage. j 

1 


16 




Reserved. 


1 



J._ 



Figure 3-14. Mask Bit Numbers Used in the STATUS Macro Instruction 
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SECTION t; COMTENTS SUPERVISION 



The contents supervision feature of the 
supervisor determines the location of 
requested programs, fetches the programs to 
main storage if necessary, and schedules 
the execution of these programs for their 
tasks. As a byproduct of these functions, 
records are kept of all programs in main 
storage. 



Contents Supervision consists of two 
types of functions: common functions and 
special functions. The common functions 
satisfy requests for linkage to a module or 
requests to fetch a module to main storage 
for future use. These common functions are 
requested by the LINK, LOAD, XCTL, SYNCH, 
and ATTACH macro instructions. These func- 
tions are performed by a group of subrou- 
tines called the "common subroutines." The 
special functions satisfy a particular 
request from a system or user routine, or 
assist one of the common functions. 
Examples of special functions are the iden- 
tification of an embedded module entry 
point, or the loading of a segment of a 
module in overlay mode. 

The common functions consist of: 



• Scheduling execution of the module by 
creating a program request block (PRB) , 
and placing it behind the current SVRB 
on the caller's RB queue. 

The special functions are used to assist 
one of the common functions or to perform a 
specialized service- Special processing is 
performed for a LOAD request, and for an 
XCTL request Issued by an SVC routine. 
Through the servicing of an IDENTIFY re- 
quest, the supervisor is informed of an 
embedded entry point within a specified 
module. Through the servicing of a DELETE 
request, the supervisor is informed that a 
module fetched because of a LOAD request is 
no longer needed in main storage. If a 
module must be loaded in overlay mode, the 
Overlay Supervisor is invoked to prepare 
for and control the loading of the appro- 
priate segments. Lastly, the actual load- 
ing of a module, although requested by 
other contents supervision components, is 
performed by the Program Fetch routine. 
This routine acts as a loader for Contents 
Supervision, the Transient Area Fetch rou- 
tine, the Overlay Supervisor, and the Stage 
3 Exit Effector. 



Searching for the requested module in 
the contents directory. 

Creating, if necessary, a contents 
directory entry (CDE) to describe the 
requested module, placing descriptive 
information in the CDE from the input 
parameters of the request, and queuing 
the CDE on the appropriate contents 
directory queue. 

Testing the module's status to deter- 
mine if it is available for use. The 
module's status is tested if a CDE is 
found in one of the contents directory 
queues or if a BLDL procedure is per- 
formed for the module. 

Causing the fetching of a module that 
is not in main storage or that is not 
reusable. 

Determining the relocated alias entry 
point and updating the appropriate con- 
tents directory queue if the module re- 
quest specifies an alias entry point. 

Deferring the request if the module is 
not available. 

Restarting a deferred request when the 
module becomes available. 



THE COMMON FUNCTIONS OF CONTENTS 
SUPERVISION 

The first part of this section describes 
the common functions in the sequence in 
which they are performed by the supervisor. 
The second part of the section describes 
each major function in greater detail in 
the logical order previously listed. 



GENERAL DESCRIPTION OF THE COMMON FUNCTIONS 

The common subroutines are entered from 
the SVC SLIH because of a LINK, LOAD, XCTL, 
or ATTACH request. If the entry is because 
of an ATTACH request, the program for which 
linkage is desired is the first program to 
be executed for the new subtask, as speci- 
fied by the ATTACH macro instruction. (See 
"Attaching a Subtask" in Section 3, "Task 
Supervision. ") 

Contents Supervision performs initiali- 
zation and input processing peculiar to the 
type of module request. Then the request 
is serviced by a group of common subrou- 
tines which locate the requested module, 
determine its status, and test whether it 
is available. A module is available if it 
is in main storage and is either reenter- 
able, or serially reusable but not in use. 
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or is nonreusable but not yet used. If the 
module is available, its execution is 
scheduled. If it is not available, it is 
fetched from auxiliary storage and then 
scheduled. If, however, the module cannot 
be fetched, the request is deferred. 

In systems that include Main storage 
Hierarchy Support, contents supervision 
service routines for LINK, LOAD, XCTL, and 
ATTACH requests direct program loading into 
the appropriate hierarchy in main storage. 
These service routines, upon entry from the 
SVC SLIH, extract the hierarchy number from 
the parameter list and, if a copy of the 
requested program is to be loaded, pass the 
number to the Program Fetch routine. The 
GETMAIN request later uses the number when 
it allocates storage for program loading. 

If hierarchy is not specified in the 
LINK, LOAD, XCTL, or ATTACH request, the 
Program Fetch routine loads the program 
into the hierarchy or hierarchies as stated 
in the scatter table. The hierarchy number 
(0 or 1) is included in the GETMAIN request 
issued for each CSECT of the requested 
module. 

Allocation of an Available Module 

If a module is available for immediate 
allocation, the "use/responsibility" count, 
which records the number of outstanding 
requests for the module, is increased and 
the module is "allocated" to the requester. 
The expression "allocated" means different 
things, depending on the type of request. 
For a LOAD request, allocation means ensur- 
ing that a load-list element exists for the 
request. A load-list element represents 
one or more LOAD requests for the module. 
It contains a "responsibility count" of the 
number of outstanding LOAD requests for the 
module, and a pointer to the contents dire- 
ctory entry which describes the module. 
For other types of requests, allocation (in 
this case scheduling) means creating a pro- 
gram request block (PRB) which will control 
the module's execution, then placing the 
PRB on the caller's RB queue, and initia- 
lizing the PRB's fields. After either type 
of allocation is complete, the appropriate 
subroutine, via the Exit routine and the 
Dispatcher, passes control to either the 
requested module or the caller. 

Deferring the Request for an 
Unavailable Module 

If a module is unavailable, it cannot be 
inunediately allocated to its requester. A 
module is unavailable if it is being 
fetched because of a previous request, or 
if it is a serially reusable module that is 
in use. In either case, the SVRB under 
whose control the supervisor is operating 
is placed on a list of waiting SVRBs. This 



list represents requests for the module 
which cannot yet be serviced. Subroutine 
CDQUECTL places the SVRB in a wait condi- 
tion, ensures a task switch (since process- 
ing for the current task cannot proceed) , 
and branches to the Dispatcher to give con- 
trol to the current routine of another 
task. 

Preparing to Fetch a Module 

If a module is not in the link pack area 
or in the job pack area for the requester's 
job step, or is nonreusable and has already 
been used, a new copy must be fetched from 
auxiliary storage. The search of the 
appropriate library requires the retrieval 
of the data set directory entry, whose 
location may be indicated by parameters in 
the caller's macro instruction. The data 
set directory is obtained via the BLDL rou- 
tine of data management. When the module 
is located, its attributes are recorded in 
a contents directory entry (CDE) that was 
built and initialized before the execution 
of the BLDL routine. 

If the data set directory entry indi- 
cates that the caller has specified an 
alias entry point, special processing is 
performed. This processing includes: 

• Determining if the module is already in 
main storage. 

• Calculating a relocated entry point 
address. 

• Ensuring that there are two CDEs for 
the module, one containing the main 
entry point name, the other containing 
the alias entry point name. 

In systems generated with storage 
hierarchies, the expansions of the LINK, 
LOAD, XCTL, and ATTACH macro instructions 
include a one-byte "hierarchy ID" value. 
This value is derived as follows: 

Value Derivation 

00 No hierarchy specified 

01 Hierarchy specified (HIARCHY=0) 

02 Hierarchy 1 specified (HIARCHY=1) 

For LINK, XCTL, and ATTACH, the hierar- 
chy identification appears as the high- 
order byte of the second fullword of the 
parameter list pointed to by register 15. 
For LOAD, the hierarchy ID is passed in the 
high-order byte of register 1. When the 
Program Fetch routine is entered, the ID is 
placed into the high-order byte of register 
5, which points to the address of BLDL. 

Fetching the Module 

After preparation for fetching the 
module is complete, control is passed to 
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the Program Fetch routine to load the 
module into main storage. The hierarchy 
identification is checked. The Program 
Fetch routine then computes the module' s 
relocated entry point address. A common 
subroutine stores the address in the mod- 
ule "s CDE for use in future linkage to the 
module. If the data set directory informa- 
tion obtained from the BLDL procedure indi- 
cates that the module is in overlay mode or 
contains TESTRAN symbol records, other rou- 
tines are invoked. If the module is in 
overlay mode. Contents Supervision issues a 
LOAD macro instruction to load nonresident 
routines of the Overlay Supervisor (lEWS- 
ZOVR) , if they are not already in storage. 
These routines are needed for later link- 
age. If the module contains TESTRAN symbol 
records, the TESTRAN routines are invoked 
via an SVC 61 instruction. 



switch. This test occurs just before a PRB 
is constructed to schedule the execution of 
the module for the current task. For a 
LOAD request, the test occurs in the 
Dispatcher. 



DETAILED DESCRIPTIONS OF THE COMMON 
FUNCTIONS 

Thus far, the general discussion of 
"Contents Supervision" has followed the 
sequence of processing used by the supervi- 
sor. This section describes each major 
function in greater detail, but not neces- 
sarily in the exact sequence in which it 
occurs. For an aid in visualizing the time 
relationships between the major functions, 
the reader may refer to the flowcharts for 
LINK, LOAD, XCTL, and SYNCH processing in 
Section 13. 



Updating the Contents Directory 

Next, a check is made to determine if 
the relocated entry point returned by the 
Program Fetch routine is an alias entiry 
point, and therefore has been stored in a 
"minor" contents directory entry (CDE) . If 
this is so, the relocated main entiry point 
is calculated and stored in the "major" 
CDE. In addition, if there are other minor 
CDEs for the module (meaning that there are 
other alias entry points), relocated entry 
points are calculated for all minor CDEs 
pertaining to the module. Thus, all per- 
tinent CDEs pertaining to the module are 
updated to contain relocated entry points. 



TSO Processing ; If the time sharing link 
pack area modules have been loaded by the 
nucleus initialization program, minor CDEs 
must be queued off the major CDEs; the 
major CDEs are obtained from SQA. 



Restarting Deferred Requests 

After calculating relocated entry points 
for the contents directory, the subroutines 
prepare deferred requests to compete for a 
new search for their desired module. Any 
other request blocks (RBs) queued to the 
module's CDE are removed and made ready. 
The RB belonging to the highest priority 
ready TCB will control the resumed search 
for the module, beginning at entry point 
CDCONTRL. 

After the RBs are made ready, a branch 
to the Task Switching routine occurs in 
order to test if any of the readied RBs 
may, the next time the Dispatcher is 
entered, replace the current RB as the con- 
troller of the module. The common subrou- 
tines later test whether the Task Switching 
routine has indicated the need for a task 



Searching for the Module 

The first function of Contents Supervi- 
sion is to search for the desired module. 
The module may be in any of several loca- 
tions: the job-step's region of main 
storage, one of the libraries of auxiliary 
storage, or the link pack area of main 
storage. Contents Supervision first 
searches the job-step's region, then (if 
appropriate) the libraries of auxiliary 
storage, and lastly the link pack area of 
main storage. 



Initially, for all module requests 
except SYNCH,*- subroutine CDSEARCH searches 
the job-step's region. In the region, mod- 
ules are assigned to subpools loosely 
called a "job pack area." Subroutine 
CDSEARCH searches for the module in the job 
pack area by examining a contents directory 
queue called a job pack area control queue. 
Each job step in the system has its own job 
pack area control queue (JPACQ).^ Each 
JPACQ contains contents directory entries 
(CDEs) that represent user modules in the 
region's job pack area. These modules may 
be used only by the job step in whose 
region they are stored. Subroutine 
CDSEARCH examines each CDE in the job 
step's JPACQ, seeking a match between the 
module name supplied as an input parameter 
and the module name contained in the CDE. 

For a IjOAD request, before the examina- 
tion of the JPACQ, another subroutine 
(CDLLSRCH) searches the load list for the 



*-For a SYNCH request the supervisor assumes 
that the module is in main storage, and 
does not search for the module. 

2The list origin for the JPACQ is the 
TCBJPQ field of the job step TCB. 
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caller's task. The load list contains ele- 
ments, each of which points to a CDE for a 
module that was loaded for the task, via a 
LOAD macro instruction. The subroutine 
examines each CDE pointed to by a load list 
element, looking for a name match, as 
described above. (See Figure U-1.) There 
are thus initially two ways to find a modu- 
le* s CDE: a search of the job pack area 
control queue, or a search of the task's 
load list. 

If a CDE is found whose entry point name 
matches that supplied as an input parame- 
ter, the module must be in the job step' s 
region of main storage. Control is then 
given subroutine CDALLOC to test the status 
of the "found" module. The module is eith- 
er immediately available, not immediately 
available, or is not available at all 
(meaning that a new copy must be fetched) . 

If subroutine CDSEARCH cannot find the 
required CDE in the JPACQ, it recognizes 
that the desired module is not in the job 
pack area, and branches to subroutine 
CDSETUP to continue the search for the 
module. (See Figure 4-2.) 

Note; If the time sharing option is 
included in the system, CDSEARCH searches 
the time sharing link pack area for a time 
sharing module entry point name. 

Job Step TCB 





1 TCBJPQ 1 


\ 



TCB for Caller's Task 



.Job Pack Queue 





1 TCBLLS 1 


\ 



|cdname| 


) 




CDNAME 



Legend: 



Figure 4-1. 



—>■ = pointer 
@ = represents a module loaded for the caller's task 

Subroutine CDSEARCH Uses the 
Load List and the Job Pack 
Queue in its Search for the 
Module's Name 



According to the contents of the DCB pa- 
rameter, an operand of the requesting macro 
instruction, the directory of the appropri- 
ate library is searched. Supervisor link- 
age to the BLDL routine of data management 
causes the loading of a directory entry 
from the specified data set for examination 
by a subroutine of Contents Supervision. 
If the DCB parameter is zero, meaning that 
a library is not specified, the directory 
of the task library, if one is present, is 
searched. If the module is not found or if 
a task library is not specified, each high- 
er task's (parent tasks in subtask's 
hierarchical structure) task library is 
searched until the job-step task is 
reached, at which point the job library, if 
one is present, for the job-step task is 
searched. Otherwise, the directory of the 
library specified by the DCB parameter is 
searched. If the desired module (actually 
the entry point name of the module) is 
still not found, subroutine CDSEARCH 
examines the other contents directory 
queue, called the link pack area control 
queue (LP ACQ) . 

The LPACQ contains CDEs describing the 
modules normally resident in the link pack 
area of main storage. In systems contain- 
ing IBM 2361 Core Storage and Main Storage 
Hierarchy Support, a secondary link pack 
area may be constructed in hierarchy 1. 
Modules in this area are loaded by the nuc- 
leus initialization program (NIP) . They 
may be shared by various job steps in the 
system. If the search of the LPACQ does 
not locate the module's name, the next step 
is to search, via the BLDL procedure, the 
directory of the link library. If the 
entry point name is not found in this di- 
rectory, the assumption is that the caller 
has made an incorrect request. According- 
ly, one of the common subroutines sets up 
an error code (806) and issues an ABEND 
macro instruction to obtain linkage to the 
ABEND SVC routine to abnormally terminate 
the caller's task. 

Creating a Contents Directory Entry 

During the search for the module, just 
before the preparation for the BLDL proce- 
dure, subroutine CDSETUP determines if a 
CDE exists. It does this by testing wheth- 
er a BLDL work area was created during a 
previous request for the module. If the 
module's CDE does not exist, space is 
obtained by the GETMAIN SVC routine. The 
CDE is then initialized and placed on the 
JPACQ. The "attributes" field (CDATTR) is 
initialized so that all bits are set. 
Later, after the BLDL routine has obtained 
the module's data set directory entry, the 
common subroutines clear the bits that are 
not applicable to the module's status. The 
entry point address field and the extent 
list address field are initialized to zero. 
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Figure 4-2. 



Further Search by the Common Subroutines of Contents Supervision if the 
Module's CDE is not in the Job Pack Queue 



(The extent list describes the entry point 
and size of each loadable section.) See 
Section 12, "Controls Blocks and Tables" 
for a description of the CDE fields. 

Testing Module Status 

There are two distinct times that the 
attributes of a module may be checked to 
determine its status. One time is after a 
CDE is found in the JPACQ or the LPACQ. In 
this case, the status-checking subroutine 
(CDALLOC) checks the bits in the attributes 
field of the CDE. Its purpose is to deter- 
mine if the module can be immediately allo- 
cated; whether the request must be deferred 
and placed on a queue of waiting reques- 
ters; or whether a new copy of the module 
should be fetched to main storage. The 
other time that the module's attributes may 
be tested is after the execution of the 
BLDL routine has found a data-set directory 
entry for the module. The attributes in 



the directory entry are tested to determine 
if the module is in main storage, recorded 
tinder another entry point name, or whether 
the module must be fetched. 

Fetching the Module 

After the BLDL routine has located the 
module on auxiliary storage, and if no 
abnormal condition has been detected, the 
appropriate subpool of main storage into 
which the module should be loaded is deter- 
mined. The module's attributes, indicated 
in the data-set directory entry, are tested 
to decide the appropriate subpool. Subpool 
252 is selected if the module is reenter- 
able, and is in either the link library or 
the SVC library. Subpool 252 is a 
supervisor-protected area within the call- 
er's region of main storage. Otherwise, 
subpool 251 is chosen. This subpool 
belongs to the job pack area for the cal- 
ler's job step. 
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Interruptions are enabled, and the 
module is loaded into the chosen subpool by 
the Program Fetch routine. If there is no 
I/O error, interruptions are again dis- 
abled, and the relocated module entry 
point, returned by the Program Fetch rou- 
tine, is stored in the CDENTPT field of the 
previously created CDE. The module's 
attributes, as indicated in the partitioned 
data set directory entry, are next tested. 
If the module is in overlay mode, the Over- 
lay Supervisor (lEWSZOVR) is loaded from 
the link library, via a LOAD macro instruc- 
tion. If the module contains TESTRAN sym- 
bol records, the TESTRAN routines are 
invoked via an SVC 61 instruction. To ind- 
icate that the module is not being loaded, 
the "not in storage" bit (NIC) is cleared. 
If the module is refreshable (eligible to 
be reloaded by the Machine-Check Handler on 
the Model 65^), the "refreshable" indicator 
REFR is set. This bit is tested by the 
Machine-Check Handler, if this recovery 
program is included in the system, when a 
machine check occurs. To indicate that the 
module is in use, the common subroutines 
set the "non-functional" flag (NFN) . These 
three bits belong to the attributes fields 
(CDATTR and CDATTR2) of the CDE represent- 
ing the module. 

Performing Alias Processing 

If the module request specifies an alias 
entry point, two types of special process- 
ing occur: one after the BLDL routine has 
obtained the data-set directory entry, the 
other after the Program Fetch routine has 
loaded the module. 

If the module request specifies an alias 
entry point name, two types of alias pro- 
cessing can occur, depending on whether the 
module is already in main storage. The 
first type determines if the requested 
module is in main storage, recorded under 
its major entry point name. This deter- 
mination is now possible, since the data- 
set directory entry is available for 
examination. The second type of processing 
ensures that all relocated module entry 
point addresses have been recorded, both 
main and alias, even though the current re- 
quest may specify only one alias entry 
point name. 

In the first type of processing, the 
common subroutines determine if the module 
is in main storage, recorded under its 



*-The Machine-Check Handler is optional sys- 
tem generation programming support for the 
System/360 Model 65 (MCH/65) , and standard 
programming support for the Model 65 Mul- 
tiprocessor, the Model 85 (MCH/85) and 
System/370. Refer to Section 2, "Inter- 
ruption Handling . " 



major entry point name. A new search is 
now necessary, since the original search 
was made under the assumption that the spe- 
cified entry point name was a major name. 
The major entry point name is obtained from 
the data-set directory entry, and the JPACQ 
is searched for this name. If the name is 
found, the JPACQ is updated to include the 
alias entj:y point name, and the Program 
Fetch routine is not invoked. If, however, 
the major entry point name is not found, 
the Program Fetch routine is invoked to 
load the module. If the module is already 
being fetched, the current request is 
deferred. 

Note: If a build entry for a time sharing 
task is marked as an alias, the time shar- 
ing link pack area is searched for the 
entry. 

In the second type of processing, the 
subroutines ensure that all relocated entry 
point addresses are recorded in the con- 
tents directory. The relocated major entry 
point address is calculated and placed in 
the module's major CDE. If there is at 
least one minor CDE queued to the major CDE 
(meaning that an alias or identified entry 
point was previously requested) , the relo- 
cated entry point address for each alias is 
calculated and stored in its related minor 
CDE. (There is one minor CDE for each 
alias or identified entry point. ) 

The calculation of the relocated entry 
points is performed by the Relocate subrou- 
tine, which is provided with certain 
inputs. The input includes the relative 
alias entry point address, obtained from 
the data-set directory entry and currently 
in the minor CDE, and the address of the 
extent list for the module, contained in 
the major CDE. The extent list, created by 
the Program Fetch routine when it loaded 
the module, contains the starting address 
of each block of main storage occupied by 
the module and the length of each block. 

Deferring a Request 

A request for a module may be deferred 
if the module is in main storage and is 
serially reusable and in use, or if the 
module is in the process of Ijeing fetched 
to main storage. In either case, the com- 
mon subroutines (entered at CDQUECTL) place 
the SVRB for the current request on a list 
of waiting SVRBs, whose list origin is the 
CDRBP field of the major CDE for the 
module. Each SVRB on the list is queued to 
the next waiting RB via its RBPGMQ field. 
A new SVRB is placed on the list according 
to the dispatching priority of its TCB. 
After joining the list of waiting SVRBs, 
the SVRB for the current request is placed 
in a wait condition, its RBWCF field set 
greater than zero. Since processing of the 
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current request cannot proceed, the need 
for a task switch is indicated to the Dis- 
patcher. The indication is the setting of 
the first word of the TCB pointer (lEATCBP) 
to zero. 

Just before the current SVRB is placed 
on the list of waiting SVRBs, the list is 
searched for an SVRB representing a pre- 
vious request from the caller's task for 
the same module. If such an SVRB is found, 
the module is permanently unavailable, and 
an error code (A06) is set up. The reques- 
ter's task is then abnormally terminated by 
the ABEND routine. 

Restarting Deferred Recpiests 

Periodically a deferred request may be 
restarted. The purpose of such restart is 
to give control of the module to the requ- 
ester representing the highest priority 
ready task. When a module is available, an 
SVRB that was previously waiting for the 
module may compete with the current SVRB 
for access to the module. According to the 
relative task dispatching priorities, the 
current request is serviced, or a deferred 
request is restarted. 

The restart procedure consists of two 
parts: preparation for restart, and the 
performance of a task switch. Preparation 
for restart can occur at two different 
times during the execution of the common 
subroutines. It can occur after the BLDL 
routine has found a data- set directory 
entry for the module. It can also occur 
after the Program Fetch routine has loaded 
the module into main storage. The task 
switch, if needed, is performed by the Dis- 
patcher after the scheduling subroutine of 
Contents Supervision (CDEPILOG) has been 
entered. 

PREPARATION FOR RESTART ; During the prepa- 
ration for restart, the DQLOAD subroutine 
makea ready the SVRBs on the waiting list, 
and determines if one of these SVRBs may 
replace the current SVRB as the controller 
of Contents Supervision. 

The DQLOAD subroutine removes from the 
waiting list any SVRBs queued to the cur- 
rent SVRB. (The current SVRB is the one 
currently controlling the execution of the 
subroutines of Contents Supervision. ) For 
each SVRB on the list, the subroutine 
clears the wait bit (RBWCF), and sets the 
RB old PSW to restart future execution at 
the beginning of the search phase of Con- 
tents Supervision (location CDCONTRL) . 
This is the point at which restart occurs, 
if a task switch is performed. 

Subroutine DQLOAD determines if any 
deferred-request SVRB can replace the cur- 
rent SVRB by comparing teak dispatching 



priorities. The subroutine invokes the 
supervisor's Task Switching routine to com- 
pare the dispatching priority of each 
deferred-request TCB with that of the cur- 
rent TCB. The result of the series of 
invocations of the Task Switching routine 
is that the TCB pointer (lEATCBP) contains 
the address of the TCB whose current rou- 
tine will next be dispatched (see "Testing 
and Indicating the Need for a Task 
Switch" ) . The current task gains initial 
control of the module. 

PERFORMANCE OF A TASK SWITCH ; If the prep- 
aration for restart has altered the TCB 
pointer, a future branch to the Dispatcher 
causes the restart of Contents Supervision 
at its search phase, under the control of 
one of its deferred- request SVRBs. The 
branch to the Dispatcher, if warranted, 
occurs during the execution of the schedul- 
ing subroutine CDEPILOG. 

CDEPILOG (entry point IEAQCS03) tests if 
an available module should be allocated to 
the current requester, or whether the Dis- 
patcher should be entered to perform a task 
switch. If the two words of the TCB point- 
er, lEATCBP and lEATCBP+U, are unequal, the 
need for a task switch has been indicated 
by the Task Switching routine. CDEPILOG 
prepares the current requester for restart 
by pointing the RB old PSW in the current 
SVRB to the beginning of CDEPILOG- The 
subroutine then branches to the Dispatcher 
to perform the task switch. The Dispatcher 
restarts Contents Supervision at entry 
point CDCONTRL, under control of the 
selected TCB and its deferred-request SVRB. 
A new search for the desired module then 
begins, as if the restarted request had 
just been issued. 

Scheduling Execution of the Module 

When the desired module is in main 
storage and is immediately usable, as indi- 
cated by the test of the CDE attributes, 
the allocation subroutine CDALLCC recog- 
nizes the need for the immediate allocation 
of the module to a requester. CDALLOC 
clears the "release" flag in the CDATTR2 
field of the major CDE for the module. The 
major CDE contains the main entry point of 
the module and a field (CDATTR) describing 
its attributes, for example, reentrant, 
"load only," etc. The "release" flag 
(CDATTR2), when cleared, indicates to the 
GETMAIN SVC routine that the space reserved 
for the module may not be reused to satisfy 
a later request for space. 

Subroutine CDALLOC branches to two other 
subroutines, CDMOPUP and CDEPILOG, to per- 
form the allocation or scheduling of the 
linkage to the module. The first step, 
performed by CDMOPUP, is to increase the 
"use/responsibility" count in the major 
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CDE. The use/responsibility count is a 
record of the number of outstanding 
requests for the module issued by LINK, 
LOAD, XCTL, or ATTACH macro instructions. 
The count is decreased by the Delete SVC 
routine or by the Exit routine when each 
execution of the module has been completed. 



CDEPILOG gets space for and initializes 
a program request block (PRB) to schedule 
and control the execution of the requested 
module. CDEPILOG obtains the information 
for initializing the PRB from information 
contained in the fields of the current 
SVRB. It places in the RB old PSW (RBOPSW 
field) of the PRB the relocated module 
entry point that was stored in the CDE. 
For an ATTACH or SYNCH request, the mode 
bit and protection key of the RB old PSW 
are duplicated from the requester's TCB. 
But for an XCTL or LINK request, the first 
word of the old PSW is obtained from the 
caller's RB. For an XCTL request, the 
first word of the caller's old PSW was 
saved in the register- zero save location of 
the caller's SVRB, before Contents Supervi- 
sion was entered. 



CDEPILOG places the newly created PRB on 
the current task's RB queue behind the SVRB 
used by Contents Supervision. Later, when 
the Exit routine is entered, the SVRB is 
removed and freed, leaving the PRB as the 
current RB for the requester's task. After 
queuing and initializing the newly created 
PRB, which controls the module's execution, 
CDEPILOG passes control to the module or to 
a restarted requester, via the Exit routine 
and the Dispatcher. 



SPECIAL FUNCTIONS OF CONTENTS SDPERVISION 

The special functions are used to assist 
one of the common functions or to perform a 
specialized service for a requester. These 
functions consist of: 

• Final processing for a LOAD request. 

• Special processing for an XCTL request. 

• Informing the supervisor of an embedded 
module entry point (IDENTIFY) . 

• Informing the supervisor that a module 
fetched via a LOAD macro instruction is 
no longer needed in main storage 
(DELETE) . 

• Supervising the loading of segments of 
an overlay module. 

• Fetching a module to main storage. 



FINAL LOAD PROCESSING 

Final processing for a LOAD request is 
performed after the desired module is in 
main storage and is available. It consists 
of checking the load list for the caller's 
task to determine if a load-list element 
exists for the requested module. 

The load list indirectly points to mod- 
ules requested for a task via the LOAD 
macro instruction. If a module was loaded 
by an alias entry point name, the load-list 
element points to a minor CDE; otherwise 
the load-list element contains a pointer to 
a module's major CDE. It also contains a 
"responsibility" count (LLCOUNT) of the 
number of LOAD requests for the module. 



If a load-list element does not exist 
for the module, a new element is con- 
structed, initialized, and placed on the 
load list for the caller's task. It is 
queued from the load-list pointer (TCBLLS) 
in the caller's TCB. 



After the load-list element is created, 
or if a determination is made that it 
already exists, the responsibility count is 
increased to include the current request. 
Control is then returned to the requester 
or to the current program of the highest 
priority ready task, via the Exit routine 
and the Dispatcher. 



SPECIAL XCTL PROCESSING 

Special processing is performed when a 
caller has issued an XCTL macro instruc- 
tion. If the macro instruction is issued 
by a user program or a user exit routine, 
processing is performed before control is 
passed to the common subroutines. If, 
however, an XCTL macro instruction is 
issued by an SVC routine, special process- 
ing is done by the transient area handler. 
The transient area handler schedules link- 
age to the desired SVC routine, and does 
not use the common subroutines of Contents 
Supervision. The simpler XCTL processing 
will be discussed first. 

Processing if the Recpiester Is a Oser 
Program or a Dser Exit Routine 

For both types of requesters (a user 
program or a user exit routine) the reques- 
ter's RB must be eliminated, since an XCTL 
request does not permit return of control 
to the requester. The Exit routine is used 
to dequeue and free the RB of the exiting 
program or routine. Depending on the type 
of requester, the RB is removed immediately 
or is removed after the requested module 
has been executed. 
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If the requester is a user program, 
operating under control of a program re- 
quest block (PRB) , the requester's PRB is 
removed immediately, before the requested 
module is obtained. This arrangement 
allows the requested program to overlay the 
requesting program, if necessary. To pre- 
pare for PRB removal, the positions of the 
caller's PBB and the SVRB for Contents 
Supervision are interchanged on the RB 
queue, so that the PRB is at the "head" of 
the queue (see Figure 4-3, part B) - 
Restart of Contents Supervision is sched- 
uled by pointing the RB old PSW in the SVRB 
to the search phase of the common subrou- 
tines (location CDADVANS) . The Exit rou- 
tine is then invoked to remove and free the 
caller's PRB (see Figure 4-3, part C) . 
After eliminating the PRB, the Exit routine 
branches to the Dispatcher to restart Con- 
tents Supervision at CDADVANS, to begin the 
search for the requested module. 

If the requester is a user exit routine, 
operating under the control of an IRB, the 
requester's Irb is removed from its RB 
queue only after the requested module has 
been obtained and executed. This delay is 
necessary because the IRB contains register 
contents belonging to the program that was 
interrupted by the asynchronous event. The 
register contents remain in the IRB until 
the Exit routine is entered after the 
requested module has been executed. 

The Exit routine is scheduled (but not 
invoked) by placing in the RB old PSW of 
the requester's IRB the address of an SVC 3 
instruction. A branch is then made to the 
common subroutines (location CDADVANS) to 
search for the requested module. When the 
module has been obtained and executed, the 
Dispatcher gives control to the SVC 3 
instruction. The instruction causes super- 
visor linkage to the Exit routine to 
dequeue and free the requester's IRB (see 
Figure 4-3, part El). 

Processing if the Requester Is an SVC 
Routine 

If the requester is an SVC routine 
operating under the control of an SVRB, the 
transient area handler's XCTL routine 
(entry point IEAQTR03) performs special 
processing. The request is handled very 
similarly to any SVC request that reaches 
the SVC Second-Level Interruption Handler. 
The following discussion will first provide 
an overview of the transient area XCTL 
function, then a more detailed coverage. 

After initial housekeeping, the Tran- 
sient Area XCTL routine performs the fol- 
lowing functions: 

• Updates the transient area queue by 
removing the requester's SVRB. 



Tests for and passes control to a 
requested routine in the link pack area 
of main storage. 



Determines if the requested routine is 
in a transient area block. 



• Preparing for linkage to the routine if 
it is in a transient area block. 

• Performs special processing to locate 
an available transient area block 
(TAB) , if the routine is not already in 
a TAB. 

• Defers the request if a TAB is not 
available. 

• Prepares for overlaying a transient 
area block, if one is available. 

• Loads the routine into an available 
TAB. 

The Transient Area XCTL routine tests if 
the requester is a resident or nonresident 
SVC routine. It tests the status bit 
(RBFNSVRB) in the requester's SVRB. 



UPDATING THE TRANSIENT AREA QUEUE ; If the 
requester is nonresident, the TAXEXIT sub- 
routine removes the requester's SVRB from 
the user queue for the TAB that contains 
the requesting routine. (The user queues 
are described in "Fetching a Nonresident 
Routine from Auxilia]:y Storage" in Section 
2, "Interruption Handling." (See Figure 
4-4.) 

The removing of the requester's SVRB 
from the user queue is necessary because 
control is not returned to the requester. 
The requesting routine is no longer a 
"user" of a transient area block. If the 
requesting routine is resident in the link 
pack area, the TAXEXIT subroutine is 
bypassed, since the requester's SVRB is not 
on a user queue. 



TESTING FOR AND PASSING CONTROL TO A ROU- 
TINE IN THE LINK PACK AREA ; The Transient 
Area XCTL routine (hereafter called the TA 
XCTL routine) next tests if the requested 
routine is in the link pack area. The test 
consists of a search of the contents direc- 
tory entries on the LPACQ. If the desired 
routine is in the link pack area, the 
requester's SVRB is flagged as "resident" 
(the RBFNSVRB bit in the RBSTAB field is 
cleared). The requester's SVRB, rather 
than the SVRB created by the SLIH after the 
current SVC interruption, will control the 
execution of the requested routine when it 
is finally dispatched. 
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Usei' Program Issues XCTL Request- 



TCB 



A. Condition of RB queue before XCTL processing. 



B. Caller's PRB and SVRB are switched during 
XCTL processing. 



C. Caller's PRB is removed by first execution 
of Exit routine. 



D. New PRB for requested module is created 
by CDEPILOG subroutine. 



E. SVRB is removed by next execution of Exit routine. 



SVRB 



PRB - 1 




Usei" Exit Routine Issues XCTL Request 



TCB 



Al . Condition of RB queue before XCTL processing. 



Bl . New PRB for requested module is created 
by CDEPILOG subroutine. 



CI . SVRB is removed by Exit routine when execution 
of Contents Supervision is complete. 



Dl . PRB for requested module is removed by the Exit 
routine after the requested module is executed. 



El . Caller's IRB Is removed by the Exit routine after 

the Dispatcher tries to restart the user exit routine. 



Legend: 

SVRB Is for Contents Supervision. 
PRB - 1 is for calling user program. 
PRB - 2 Is new PRB for requested module. 
IRB Is for calling user exit routine. 



RB for routine being 
executed when csynch. 
event occurred 




Figure 4-3. Manipulation of the Caller's RB Queue During Servicing of an XCTL Request 
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-Ua 



SVRB 



PKB 



TC3 




PRB 



^^WB~ 



/ 



TCB 



Pn.B TCB 

/ 




Transient Area Block 1 (TAB 1) 

4> 



Transient Area Block 2 (TAB 2) 



KL. 



/ 



SVRB [ PRB 



/ 



TCB "-^ 



./ 



^SVRB 




PRB 




TCB 


/ 


/ 


,* 






y 



/ 



Figure 4-4. The Transient Area Queues 
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The TA XCTL routine prepares for the 
passing of control to the routine as fol- 
lows. It sets up registers, and points the 
RB old PSW in the requester's SVRB to the 
address of the desired routine. This is 
the PSW that is loaded by the Dispatcher to 
give control to the routine. The TA XCTL 
routine then uses an SVC 3 instruction to 
gain linkage to the Exit routine- The Exit 
routine removes from the RB queue and free 
the SVRB created for the current XCTL re- 
quest, since it is no longer needed. Con- 
trol is then passed to the desired routine, 
via the Dispatcher. 



DETERMINING IF THE ROUTINE IS IN A TRAN- 
SIENT AREA BLOCK ; If the requested routine 
is not in the link pack area, as indicated 
by the search of the LPACQ, the assumption 
is that the routine is nonresident. The 
TAXCTL routine then determines if the SVC 
routine is in one of the transient area 
blocks (tabs) of main storage into which 
nonresident routines are loaded. If the 
routine's name is in the permanent SVRB for 
a TA fetch task, the routine is currently 
in a TAB. (See "Fetching a Nonresident 
Routine From Auxiliary Storage" in Section 
2, "Interruption Handling.") Accordingly, 
the TA XCTL routine prepares for linkage to 
the SVC routine. 



PROCESSING IF THE ROUTINE IS IN A TRANSIENT 
AREA BLOCK ; The TA XCTL routine then 
steres data in the requester's SVRB that is 
needed to "refresh" the routine in case it 
is overlaid in the TAB before its execution 
is complete. This data includes the rela- 
tive track and record address of the rou- 
tine on auxiliary storage (obtained from 
the TACT entry) , the routine length, the 
right half of the routine name, and the 
displacement of the TACT entry for the TAB 
in which the routine currently resides. 
The routine's name and length are obtained 
from the permanent SVRB belonging to the 
transient area fetch task associated with 
the TAB. The displacement of the TACT 
entry is calculated from the TACT address. 



The TA XCTL routine then increases the 
"user" count for the transient area blocks. 
This count of the total number of user 
SVRBs of all TABS is examined during the 
execution of the TA Refresh routine when 
the Dispatcher is next entered. After 
increasing the user count, the TA XCTL rou- 
tine places the requester's SVRB on TAB'S 
user queue, in order to keep track of the 
users of the TAB (see Figure 4-4) . 

The preparation for the passing of con- 
trol to the nonresident routine is identi- 
cal to that previously described for a rou- 
tine resident in the link pack area. 



PROCESSING IF THE ROUTINE IS NOT IN A TRAN- 
SIENT AREA BLOCK ; If the name of the SVC 
routine is not in the permanent SVRB for a 
TA fetch task, the routine is not already 
in a TAB. The TA XCTL routine then tries 
to obtain a TAB into vdiich it may place the 
routine. It examines the transient area 
control table and the user queues to find a 
TAB that is available. (See Figure 4-4 and 
Section 12, "Control Blocks and Tables.") A 
TAB is available in any of the following 
cases: 

• The TAB is not being used. 

• The TAB has no using SVRBs that are 
ready. 

• The TAB may be overlaid by the 
requested routine. It may be overlaid 
if the task dispatching priority of its 
current user is lower than that of the 
requester. 

If a TAB is not available, the request 
is deferred. If, however, a TAB is avail- 
able, the requested routine is loaded into 
it. When the fetch process is complete, 
control is passed to the routine, via the 
Dispatcher. 

DEFERRING THE REQUEST ; This discussion 
will first consider the case in which an 
available TAB cannot be found. If a TAB is 
not available, the TA XCTL routine defers 
the current request by placing the current 
SVRB on the transient area request queue 
(see Figure 4-4) . The request queue is a 
list of SVRBs whose routines cannot be 
immediately scheduled for execution. The 
TA XCTL routine places the current SVRB 
into a wait condition, since execution of 
the current request cannot continue. To 
schedule the restart of this request, the 
TA XCTL routine points the RB old PSW in 
the SVRB to the "retry" entry point, called 
TAXRETRY. Then, to permit the Dispatcher 
to pass control to the current routine of 
another task, the TA XCTL routine indicates 
the need for a task switch (sets location 
lEATCBP equal to zero) and branches to the 
Dispatcher. 

PREPARATION FOR THE OVERLAYING OF A TRAN- 
SIENT AREA BLOCK : If an available TAB is 
found, the TA XCTL routine prepares to 
fetch the SVC routine to the TAB. It sets 
into a wait condition the SVRBs on the 
tab's user queue, which represent active 
requests for the routine currently in the 
TAB. Then, to delay attempted execution of 
the requested routine until it is fetched, 
the TA XCTL routine sets the requester's 
SVRB in a wait condition. Then, to permit 
entry to the routine after it has been 
fetched, the TA XCTL routine points the RB 
old PSW in the SVRB to the address of the 
TAB. This address is the entry point of 
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the routine when the fetch is complete. To 
prevent accidental overlay of the TAB dur- 
ing the fetch process, the transient area 
control table (TACT) entry is flagged to 
indicate that the TAB is being loaded. 



The extent of fetch processing (that is, 
whether a BIjDL macro instruction must be 
issued) is determined by whether the DE 
operand was specified in the XCTL macro 
instruction. If the DE operand was speci- 
fied, the TA XCTL routine sets the RB old 
PSW in the transient area fetch SVRB 
(queued to a transient area fetch TCB) to 
bypass the BLDL procedure. (See Figure 
U-H.) But if the DE operand was not speci- 
fied, the RB old PSW in the transient area 
fetch SVRB is set to enter the BLDL 
procedure. 

In either case, the TA XCTL routine 
invokes the supervisor's Task Switching 
routine to prepare for a switch to a tran- 
sient area fetch task, under which the 
fetch is performed. Then, to schedule 
removal of the SVRB for Contents Supervi- 
sion, the RB old PSW in that SVRB is set 
for future entry to the Exit routine. The 
Exit routine is entered when the Transient 
Area Fetch routine waits for I/O completion 
and the requester's task again receives 
control. A branch is made to the Dispatch- 
er, which passes control to the Transient 
Area Fetch routine to load the requested 
SVC routine. 



INFORMING THE SUPERVISOR OF AN EMBEDDED 
MODULE ENTRY POINT 

The Identify SVC routine informs the 
supervisor of a module's embedded entry- 
point name that was not established by the 
Linkage Editor. The routine informs the 
supervisor by creating a CDE to represent 
the embedded entry-point name. The Identi- 
fy routine is a type-2 SVC routine (resi- 
dent, SVC-issuing, disabled) . It is 
entered from the SVC Second-Level Interrup- 
tion Handler after an SVC 41 instruction 
has been issued. 

The Identify routine searches the con- 
tents directory queues (JPACQ and LPACQ) 
for the specified entry-point name. The 
name can be the major name of a module, an 
alias name of a module, or a name specified 
in a previous IDENTIFY macro instruction. 
If the specified entry-point name cannot be 
found, the routine then determines if the 
specified entry-point address is valid. 
The entry-point address is valid if it 
exists in either the caller's module, or in 
a module which was loaded for the caller's 
task. 



If the entry-point name cannot be found 
in the contents directory, and if the 
entry-point address is valid, the routine 
creates a minor CDE, which defines the 
identified entry point, and queues it to 
the module's major CDE. The Identify rou- 
tine then sets up a return code indicating 
the result of its search, and returns con- 
trol to the caller, via the Exit routine 
and the Dispatcher. 

Upon entry (at location IGCOtl) the 
Identify routine first tests if the caller 
is a valid user program. The routine 
determines if the caller is valid by test- 
ing the type of RB under which the caller 
is operating. (The test is of the RBFTP 
subfield in the RBSTAB field.) If the RB 
is not a PRB, the caller is invalid. 
Accordingly, the Identify routine sets up a 
return code of X'lO' , and via the Exit rou- 
tine and the Dispatcher, returns control to 
the caller. If the test of RB type indi- 
cates that the caller is valid, the Identi- 
fy routine begins its search for a contents 
directory entry (CDE) that may contain the 
desired entry-point name. 

The Identify routine prepares to search 
both the link pack area queue and the job 
pack area queue for the caller's job step. 
(Each job step has its job pack area within 
its own region of main storage. ) The rou- 
tine searches the CDEs of the queues for a 
match between the input entry name, supp- 
lied as an operand of the IDENTIFY macro 
instruction, and the entry name in a CDE. 

If a CDE is found whose entry-point name 
agrees with the requested name, the Identi- 
fy routine determines if the CDE is a minor 
CDE by testing the MIN flag of its CDATTR 
field. A minor CDE contains either an 
alias entry- point name (established by the 
linkage editor) , or an entry-point name 
provided by a previous execution of the 
Identify routine. 

If the CDE is not a minor CDE, it repre- 
sents a major entry-point name for the 
module. Since the located entry point is 
not an alias, the Identify routine sets up 
an error code of X'08', indicating that the 
specified entry-point name is the same as 
the major name of a module currently in 
storage. The routine then returns control 
to the caller, via the Exit routine and the 
Dispatcher. 

If, however, the CDE is a minor CDE, the 
Identify routine compares the requested 
entry-point address with the address con- 
tained in the CDE. If these addresses are 
the same, a previous IDENTIFY macro 
instruction specifying the same entry-point 
address was issued. A return code of X'04* 
is used to inform the caller. But if the 
two entry- point addresses are unequal, a 
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previously issued IDENTIFY macro instruc- 
tion specified the same entry-point name 
but a different address. In this case, the 
routine informs the caller with a return 
code, of X'lt', and returns control, via 
the Exit routine and the Dispatcher. 

If in its search of either of the CDE 
queues, the Identify routine does not find 
a CDE containing the specified entry- point 
name, it makes an initial assumption that 
the entry point lies within the caller's 
module. The routine then examines the 
extent list for the caller's module to 
determine if the desired entry- point 
address is in the module. The extent list 
for a module contains the starting address 
and length in bytes for each control sec- 
tion of the module. (The Identify routine 
obtains the address of the extent list for 
the caller's module from the module's CDE 
CDXLMJP field). See Figure H-5. The 
extent-list pointer was placed in the CDE 



by the Program Fetch routine. The address 
of the CDE for the current module, in turn, 
is contained in the caller's PRB (RBCDE 
field) . 

If the entry-point address is found, the 
Identify routine creates and initializes a 
minor CDE. If, however, the entry- point 
address is not found, the routine continues 
its search for a module that contains the 
address. The continued search is made via 
the load list for the caller's task. This 
list represents the LOAD requests for 
modules made for this task. (See "Load 
List" in Section 12, "Control Blocks and 
Tables.") 

For each load-list element, the routine 
first obtains the CDE pointer in that ele- 
ment (LLCDPTR) to gain access to the 
related CDE (see Figure 4-5) . Each CDE, as 
stated before, contains a pointer to an 
associated extent list. The Identify rou- 
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Figure 4-5. Finding an Extent List by Searching the Job Pack Queue or the Load List 
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tine then examines the extent list in the 
same way It had examined the extent list 
for the caller's module. The routine 
examines the extent list indirectly pointed 
to by all elements in the load list belong- 
ing to the caller's task. If a module con- 
taining the specified entry- point address 
is not found, the Identify routine indi- 
cates this result by a return code of 
X'OC. It then returns control to the 
caller, via the Exit routine and the 
Dispatcher. 

If the desired entry-point address is 
found, the Identify routine next creates a 
minor CDE to represent the desired entry- 
point name. It issues a GETMAIN macro 
instruction to obtain space for the new CDE 
(24 bytes from subpool 255, supervisor 
queue area) . The routine then initializes 
the subfields of the CDE (MIN, REN, SER, 
and NLR) to indicate that the CDE repre- 
sents a minor entry point and to indicate 
the module's attributes. (See Section 12, 
"Control Blocks and Tables" for a descrip- 
tion of these subfields.) After initializ- 
ing the new CDE, the routine queues it to 
the appropriate CDE queue. 

Then, setting up a return code of X'OO' 
to indicate successful completion of the 
IDENTIFY request, the routine returns con- 
trol to the caller, via the Exit routine 
and the Dispatcher. 



INFORMING THE SUPERVISOR OF A MODULE LOADED 
DIRECTLY INTO MAIN STORAGE 

The Identify SVC routine may be used to 
create a major CDE and extent list for a 
module brought directly into main storage 
by the loader. This allows the supervisor 
to identify the module. 

The caller provides the Identify routine 
with the address and lengths of the modu- 
le's extents, the entry point, and module 
name. If the entry point is not already in 
the link pack or the caller's job pack 
queue, and the entry point is within one of 
the specified extents, the Identify routine 
creates a major CDE and queues it on the 
user's job pack area control queue. It 
flags the CDE as "not loadable only", in 
subpool zero, and "with no backup copy, " 
and builds the extent list. The routine 
y", then moves the extent list into subpool 
255. 

Upon entry (at location IGC041) the 
Identify routine determines whether the 
caller is a valid user program by testing 
the type of RB under which the caller is 
operating. (The test is of the RBFTP sub- 
field in the RBSTAB field.) If the RB is 
not a PRE, the caller is invalid. Accor- 
dingly, the Identify routine sets up a 



return code of X'lO", and returns control 
to the caller via the Exit routine and the 
Dispatcher. If the test of RB type indi- 
cates that the caller is valid, the Identi- 
fy routine checks the caller's parameter 
list. If the parameter list is not on a 
doubleword boundary, or if the first byte 
of the parameter list is not zero, the 
Identify routine sets up a return code of 
X'18' and returns control to the caller via 
the Exit routine and the Dispatcher. 
Otherwise, the Identify routine checks the 
extent list length (EXLLNTH) and extent 
length addresses. If the extent list 
length is not positive or not a multiple of 
eight, or if the extent addresses are not 
on doubleword boundaries, the Identify rou- 
tine returns control to the caller via the 
Exit routine and the Dispatcher with a 
return code of X'lC. If the extents are 
on doubleword boundaries, the routine 
checks that they are in subpool zero. If 
they are not. Identify returns control to 
the caller with a return code of X'20*. 

If the extents are in subpool zero, the 
Identify routine searches the job pack area 
queue and the link pack area queue for the 
caller's job step. (Each job step has its 
job pack area within its own region of main 
storage.) The routine first searches the 
CDEs of the job pack area queue for a match 
between the input entry name, supplied in 
the parameter list for the IDENTIFY macro 
instruction, and the entry name in a CDE. 

If a CDE is found whose entry-point name 
agrees with the requested name, the Identi- 
fy routine determines if the CDE is a minor 
CDE by testing the MIN flag of its CDATTR 
field. A minor CDE contains either an 
alias entry-point name (established by the 
linkage editor) , or an entry-point name 
provided by a previous execution of the 
Identify routine. 

If the CDE is not a minor CDE, it repre- 
sents a major entry-point name for the 
module. Since the located entry point is 
not an alias, the Identify routine sets up 
an error code (8), indicating that the spe- 
cified entry-point name is the same as the 
major name of a module currently in 
storage, and returns control to the caller, 
via the Exit routine and the Dispatcher - 

If, however^ the CDE is a minor CDE, the 
Identify routine compares the requested 
entry-point address with the address con- 
tained in the CDE. If these addresses are 
the same, a previous IDENTIFY macro 
instruction specifying the same entry-point 
address was issued. A return code of X'OU' 
is used to inform the caller. But if the 
two entry- point addresses are unequal, a 
previously issued IDENTIFY macro instruc- 
tion specified the same entry-point name 
but a different address. In this case, the 
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routine informs the caller with a return 
code of X'lH', and returns control to the 
caller via the Exit routine and the 
Dispatcher. 

If, during its search of either of the 
CDE queues, the Identify routine does not 
find a CDE containing the specified entry- 
point name, it examines the extent list 
specified in the parameter list supplied by 
the calling routine to determine if the 
disired entry-point address is in the 
module. The extent list for a module con- 
tains the starting address and length in 
bytes for each control section of the 
module. 

If an extent containing the specified 
entry-point address is not found, the Iden- 
tify routine indicates this with a return 
code of X'OC It then returns control to 
the caller, via the Exit routine and the 
Dispatcher. If the entry- point address is 
found, the Identify routine creates and 
initializes a major CDE and extent list. 

Identify issues a GETMAIN macro instruc- 
tion to obtain space for the new CDE and 
extent list (from subpool 255, supervisor 
queue area). The routine then initializes 
the subfields of the CDE (SPZ, XLE, and 
NLR) to indicate that the CDE represents a 
major entry point and to indicate the modu- 
le's attributes. (See Section 12, "Control 
Blocks and Tables" for a description of 
these subfields . ) After initializing the 
new CDE, the routine queues it to the cal- 
ler's job pack area control queue. Then, 
setting up a return code of X'OO' to indic- 
ate successful completion of the request, 
the routine returns control to the caller, 
via the Exit routine and the Dispatcher. 



INFORMING THE SOPERVISOR THAT A LOADED 
MODULE IS NO LONGER NEEDED IN MAIN STORAGE 

The Delete SVC routine is used by a sys- 
tem or user program to indicate to the 
supervisor that a module previously fetched 
via a LOAD macro instruction is no longer 
needed in main storage. The routine 
searches the current task' s load list in 
order to find the contents directory entry 
(CDE) representing the module to be 
deleted. If the routine does not find the 
CDE, it returns control to the caller, via 
the Exit routine and the Dispatcher, with a 
return code indicating that no record of 
the module can be found. If the routine 
finds a record of the specified module, it 
reduces a "responsibility" count of the 
number of LOAD requests. In addition, if 
the module is not in use and there are no 
outstanding requests for its use, the 
Delete routine, via subroutine CDHKEEP, 
frees the space occupied by the module, its 
extent list, and its CDEs, thus removing 



all traces of the module from main storage. 
The Delete routine then returns control to 
the caller, via the Exit routine and the 
Dispatcher. 

Upon entry (at address IGC009) the 
Delete routine first searches the load list 
for the caller's task in order to find a 
contents directory entry (CDE) containing 
the specified entry-point name- If such a 
CDE can be found, processing of the request 
can continue. Otherwise, the routine sets 
up a return code (i») and returns control to 
the caller, via the Exit routine and the 
Dispatcher. The Delete routine obtains the 
load-list origin from the TCBLLS field of 
the current TCB (see Section 12, "Control 
Blocks and Tables" ) . It searches the ele- 
ments of the load list, examining each CDE 
pointed to by each load list element. If 
it does not find a match between the speci- 
fied entry-point name, supplied as an input 
parameter of the macro instruction, and the 
name in any of the CDEs indicated by the 
load list, the return code is set up and 
control is returned to the caller, as 
stated previously. If the routine finds a 
match, processing continues as follows. 

The Delete routine subtracts one from 
the "responsibility" count (LLCOONT) in the 
load list element for the specified module. 
This count is a record of the number of 
outstanding LOAD requests for the module. 
(See Section 12, "Control Blocks and 
Tables.") Each execution of the Delete rou- 
tine similarly decreases the responsibility 
count until the count reaches zero. The 
routine next checks iidiether this count has 
reached zero. A responsibility count of 
zero indicates that there are no outstand- 
ing LOAD requests, that is, there have been 
as many delete requests for the module as 
there have been LOAD requests. If the 
responsibility count in the load list ele- 
ment is zero, the routine removes the ele- 
ment from the load list, and issues a FREE- 
MAIN macro instruction to free its space. 
This action is appropriate, since a load 
list element merely indicates an outstand- 
ing LOAD request for a module, not whether 
the module has been fetched via another 
type of macro instruction, or whether the 
module is still being used. 

The Delete routine next subtracts one 
from the "use/responsibility" count in the 
major CDE that it has found. This count, 
unlike the responsibility count in a load 
list element, records the total number of 
requests for a module, via ATTACH, LINK, 
LOAD, or XCTL macro instructions. The 
count is increased for each such request 
and decreased for each DELETE or SVC 3 
instruction. 

The routine tests the use/responsibility 
count in the major CDE to determine if the 



88 



module's storage areas may be freed. These 
areas include the space occupied by the 
module, its CDEs, and its extent list. If 
the count is not zero, at least one requ- 
esting program within the current task has 
not completed its use of the module. That 
is, the module has not yet issued a RETURN 
macro instruction, nor has a DELETE macro 
instruction been issued for it. Since the 
module's storage areas cannot be freed, the 
routine returns control to the caller, via 
the Exit routine and the Dispatcher. 

If, however, the use/responsibility 
count is zero, the Delete routine turns off 
bits in the CDATTR field to indicate that 
the module is neither reentrant nor reus- 
able and then branches to subroutine 
CDHKEEP to free the storage space occupied 
by the module, its extent list, and its 
CDEs (both major and minor CDEs, if both 
types exist) . The address of the extent 
list for the module is obtained from its 
major CDE. After freeing the module's 
storage space, the Delete routine returns 
control to the caller, via the Exit routine 
and the Dispatcher, with a return code of 
zero. 
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Figure 4-6. Organization of an Overlay 
Module 



SUPERVISING THE LOADING OF SEGMENTS OF AN 
OVERLAY MODULE 

The Overlay Supervisor directs the load- 
ing of segments of an overlay module. 
Before the execution of an overlay module, 
the linkage editor builds two sets of 
tables, the segment table and the entry 
tables, which it places in the overlay 
module. Later, during execution of the 
module, the Overlay supervisor uses and 
alters information in the tables to perform 
its functions. 

Preparatory Linkage Editor Functions 

Before execution of an overlay module, 
the linkage editor builds, from information 
in the relocation list dictionary (RLD) and 
the user's control statements, a segment 
table and one or more entry tables. These 
tables are made a part of the overlay 
module and are used by the Overlay Supervi- 
sor during module execution. 

There is only one segment table (SEGTAB) 
in an overlay module, as shown in Figure 
H-6. The segment table is used to keep 
track of the relationship of the segments 
in the module, and to determine which seg- 
ments are in main storage or are being 
loaded. 

The linkage editor builds an entry table 
for each segment that contains V-type 
address constants. (See Figure H-6.) A 
table entry is made for each constant that 
refers to a symbol whose segment must be 



fetched via a CALL or branch instruction. 
The linkage editor saves in each entry the 
value it assigns to the constant. It 
places in the value field of the constant 
the address of the ENTAB entry. 

During module execution, when the branch 
instruction that uses the address constant 
is executed, the branch gives control to an 
instruction in the associated ENTAB entry. 
Instructions in the ENTAB provide supervi- 
sor linkage to the Overlay Supervisor if 
the desired segment is not in main storage. 
If the segment has been fetched by the 
Overlay Supervisor, instructions in the 
ENTAB provide a branch to the segment. 

If Main Storage Hierarchy Support is 
included in the system, the loading of 
overlay structure programs can be directed 
into hierarchy or hierarchy 1 by the 
parameter HIARCHY=, but segments of a pro- 
gram written in overlay mode cannot be 
loaded into different hierarchies. When 
hierarchy is not specified, the overlay 
structure exists in hierarchy . 

Functions of the Overlay Supervisor 

The Overlay Supervisor receives control 
either when an overlay segment issues a 
SEGLD or SEGWT request for another segment, 
or when a segment issues a CALL or branch 
instruction to an external address in 
another segment not in main storage. In 
both cases, the Overlay Supervisor examines 
the segment table to determine whether the 
requested segment is already in main 
storage, and whether all segments in its 
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path have been loaded. It then causes the 
loading of the requested segment, if not 
already in main storage, and any needed 
segments in its path. The actual loading 
is performed by the Program Fetch routine. 

When loading is complete, and the caller 
has issued a CALL or branch instruction, 
the Overlay Supervisor alters the entry 
tables of the loaded segments. The modi- 
fied entry tables permit future branches to 
the same points in the loaded segments 
without help from the Overlay Supervisor. 

Lastly, depending on the type of invok- 
ing macro instruction, control is given to 
the: 

• Caller before loading is complete 
(SEGLD) . 

• Caller after loading is complete 
(SEGWT) . 

• Branch address in the requested segment 
after it is loaded (CALL or branch 
instruction) . 

Linkage to the Overlay Supervisor 

Linkage to the Overlay Supervisor is 
initiated directly for a SEGLD or a SEGWT 
macro instruction. It is initiated 
indirectly for a CALL or branch 
instruction . 

DIRECT SDPERVISOR LINKAGE ; When the expan- 
sion of a SEGLD or SEGWT macro instruction 
is issued, an SVC (37) interruption occurs 
and control is given, in turn, to the SVC 
First-Level Interruption Handler, the SVC 
Second-Level Interruption Handler, and to 
resident module IGC037 of the Overlay 
Supervisor. If direct branch entry to the 
requested segment, via the caller's ENTAB, 
has been prepared through a previous branch 
or CALL, control is returned to the caller 
(see Figure 4-7). In this case, further 
processing of the current request is not 
needed. But if a direct branch entry has 
not been prepared, module IGC037, after 
performing initialization, issues a LINK 
macro instruction to obtain supervisor 
linkage to the nonresident module lEWSZOVR. 
This module processes the request, as 
described in "Types of Processing." 

SUPERVISOR LINKAGE VIA THE CALLER'S ENTRY 
TABLE ; When a branch instruction or CALL 
macro instruction in an overlay segment is 
executed, specifying a V-type address con- 
stant, a branch is made to the associated 
ENTAB entry, which branches to an SVC H5 
instruction in the last ENTAB entry. The 
SVC 45 instruction causes supervisor link- 
age, via the SVC First-Level and Second- 
Level Interruption Handlers, to resident 
module IGC037 of the Overlay Supervisor 



(see Figure 4-8, A, B, and C) . After per- 
forming initialization, module IGC037 
issues a LINK macro instruction to obtain 
supervisor linkage to the nonresident 
module lEWSZOVR. This module processes the 
branch request, as described in "Types of 
Processing." 

Types of Processing 

During execution of an overlay module, 
the loading of a requested segment and the 
passing of control depend on the type of 
instruction that the caller has issued and 
whether: 

• The requested segment is in main 
storage . 

• A SEGLD request is being processed. 

• A CALL or branch instruction was pre- 
viously issued specifying the same 
external address. 

The type of processing for each set of 
conditions is summarized in Figure 4-9. 

Determining the Segments that Must Be 
Loaded 

The nonresident module (lEWSZOVR) of the 
Overlay Supervisor determines which seg- 
ments should be loaded. It does this by 
scanning the segment table of the overlay 
module, which was loaded with the root seg- 
ment- It examines status indicators in the 
segment table, previously set by the link- 
age editor or the Overlay Supervisor, to 
determine which, if any, segments in the 
path of the requested segment must be 
loaded. For each segment that must be 
loaded, lEWSZOVR sets indicators to control 
a subsequent fetch process. 

The segment table, a part of the root 
segment, was built by the linkage editor. 
It contains one entry for each segment of 
the overlay module. The entries are 
ordered to correspond to the segment num- 
bers of the overlay structure. Each entry 
contains the number of the preceding seg- 
ment in the path and a field of status 
indicators. The segment table entries form 
a tabular representation of the overlay 
tree structure. Figure 4-10 illustrates a 
typical segment table for a "single-region" 
overlay structure. (An overlay program can 
be designed in single or multiple regions 
of main storage — not to be confused with 
job-step regions. (See the Linkage Editor 
publication for further infoinnation.) 

During the scan of the segment table, 
the entry for the requested segment is 
located and its status indicators are 
examined. The resultant processing is 
tabulated in Figure 4-11. 
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Figure H-1 . Functional Flow of Overlay Supervisi^sn 



Section 4: Contents Supervision 91 



SEGTAB 



R 
O 
O 
T — 

S 

E 



Sfep A 



SEGl 


CSECT 






ENTRY 


'EASY 





L 
— BR 


15, ADCONl 
15 


EASY 


• 
SR 


1,1 


ADCONl 


DC 


V(FOX) 



L. 



E 
N 
T 
A 



B DISP(15,0) 



Address of FOX 



Seg. no. 
of FOX 



-Step B — 



-StepC- 



SVC45 



Overlay Supervisor 



-Step D- 



Program Fetch 



SEG2 


CSECT 
ENTRY FOX 


FOX 


• 

AR 1,2 




• 




• 




• 



T, 



I 

Step B-1 



L 15,4(0,15) 



BR 15 



Address of SEGTAB 



SEG3 


CSECT 

• 




ADCON2 


• 

L 

BR 

• 

• 

DC 


15,ADCON2 
15 

V(EASY) 



Le.qend: 



-Step E ■ 



>■ = control flow 
-^- = loop processing with 
a subroutine 



Figure H-8 . Use of the Caller's ENTAB to Branch to a Segment 



Controlling the Loading of Needed Segments 

The loading of needed segments is per- 
formed in two different ways, depending on 
whether the current request is made via a 
SEGWT or a SEGLD macro instruction. 

For a SEGWT request, lEWSZOVR, as part 
of the caller's task, directly invokes the 
Program Fetch routine to load each segment 
whose SEGTAB entry is marked 01 ("loading 
scheduled"). The caller is given control 
only after all such segments have been 
loaded. 

For a SEGLD request, lEWSZOVR attaches 
as a subtask the SEGLD Processor routine 
(OVLALD02) which, under control of the sub- 
task TCB, invokes the Program Fetch routine 
to load each segment. As with a SEGWT 
request, each segment is loaded whose SEG- 
TAB entry is marked 01 ("loading sched- 



uled"). However, at the first I/O wait 
interval, control is returned to the issuer 
of the SEGLD macro instruction, although 
the needed segments have not yet been 
loaded. Later, if the caller tries to 
branch to the requested segment before 
loading is complete, its task is forced to 
wait. While the caller's task waits, the 
SEGLD Processor routine completes the load- 
ing of the needed segments, and then posts 
an event control block to ready the waiting 
task. 

Preparation for an Dnasslsted Branch to the 
Loaded Segment 

When the requested segment and any 
needed segments in its path have been 
loaded, it is desirable to permit the call- 
er to branch to the requested segment via 
its ENTAB, without help from the Overlay 
Supervisor. Such an unassisted branch 
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Instruc- 
tion 

t— 

SEGLD 
(SVC 37) 



^ 

1. Requested segment and/or segments 
in its path are not in main stor- 
age, and are not in process of 
being loaded. 



h 



SEGWT 
(SVC 37) 



h 



I 

CALL 

or 

branch 

(SVC 45) 



Conditions 



2. Requested segment is in main stor- 
age or is being loaded. 



3. Same conditions as in (1). 



4. Recpiested segment is being loaded 
for a SEGLD request. 



5. Requested segment is in main stor- 
age. 



Segment was requested via SEGLD or 
SEGWT and is in main storage. 



Segment was requested via a SEGLD 
and loading is not complete 



8. Requested segment is not in main 
storage, nor is it being loaded. 



h 



Caller previously issued a CALL or 
branch instruction specifying same 
external address. 



Major Processing 



^ 

1. Loading of needed segments is start- 
ed. The caller's entry table is not 
altered to prepare for a branch to 
the requested segment. Control is 
returned to the caller while the 
segment or segments are being 
loaded. The requested segment is 
not entered. 

, 

2. Control is returned to the caller. 



1 

3. Needed segments are loaded. The 
caller's entry table is not altered 
to prepare for a branch to the 
requested segment, control is 
returned to the caller only after 
the requested segment and any needed 
segments in its path have been 
loaded. The requested segment is 
not entered. 

\ 

H. Processing of the SEGWT request 

waits until loading is complete. No 



new loading occurs, 
cessing is as in (3) . 



Remaining pro- 



5. control is returned to the caller. 



The caller's entry table is altered 
to prepare for a future branch to 
the same external address without 
entry to the Overlay Supervisor. 
Control is then given to the 
requested segment at the specified 
address. 



7. Processing of the CALL or branch 
request waits vintil loading is com- 
plete. No new loading occurs. 
Remaining processing is as in (6) . 



8. Needed segments are loaded. When 
loading is complete, the remaining 
processing is the same as in (6) . 



9. Overlay Supervisor is not entered. 
The caller's entry table, previously 
altered as in (6), provides a direct 
branch to the requested segment. 



Figure H-9. Types of Processing During Overlay Supervision 



Section 4; Contents Supervision 93 



Segment 1 
2 
3 
4 
5 
6 
7 



I No.-of- 
Segmenl 

' ■ 


Preceding 
Field 


Status j 
Indicators i 





f V _j ;\' : : I. >2erii 'i: 




1 


(when cdiler chain existsy' 




1 


: ;\;::Aadress5>f:ENTAB entry 
V^^(when-sd||er"cHam exis 




2 


#; Address of ENTAB entry 

; (when caller chain exists) s:--: 




2 


;:^;;iAddre!iS;pf ENTABentry J'-:S:\ 
:;;(v\Jien;cql.ler chqiri exists), . ■ ;, 




5 


;i;;A^dress: of ENTAB entry ;■■; 
L: ;(when caller chain exists) ;; 




5 


;: . Address of ENTAB entry . . ; V 
/ (when caller chain exists); :,- 





2 

4 5 

6 7 



Figure 4-10. 



Organization of SEGTAB 
Entries for a Single-Region 
Overlay Structure 



would bypass the SVC 45 instruction in the 
caller's ENTAB (see steps A, B-1, and E of 
Figure 4-7) . 

The alteration of the caller's ENTAB 
occurs after the caller has issued its 
first CALL or branch instruction to obtain 
linkage to the requested segment. The CALL 
or branch instruction may itself cause the 
loading of the segment Csee Figures 4-7 and 
4-9). 

When module lEWSZOVR is entered after an 
SVC (45) interruption, it alters the call- 
er's ENTAB when it has determined that the 
requested segment is in main storage, or 
when it has loaded the segment. It adds 2 
to the displacement (DISP) field of the 
ENTAB entry through which the branch to the 
SVC 45 instruction was routed (see Figure 
4-8, Step B) . When the caller executes 
another branch to this ENTAB entry, the SVC 
45 instruction will be bypassed, and con- 
trol will be given to the second field of 
the last ENTAB entry (see Figure 4-8, Step 
Bl) . Execution of the instruction in this 
field will cause general register 15 to be 
loaded with the value assigned to the 
address constant (in the example, the 



address of FOX) . A branch to that location 
in the requested segment will then be 
executed. 

All entry tables in the same overlay 
region that have been altered to bypass the 
SVC 45 instruction are chained together in 
a "caller chain. " A pointer to the last- 
altered entry table is placed in the seg- 
ment table. When a segment is to be over- 
laid, module lEWSZOVR uses the appropriate 
caller chain to reset all modified entry 
tables that refer to the segment to be 
overlaid. Thus, an unassisted branch can- 
not occur to a segment no longer in main 
storage. The resetting of ENTAB entries in 
a caller chain accompanies the processing 
shown for condition 4 of Figure 4-11. 

Passing of Control 

The last function of the Overlay Super- 
visor is to pass control. Control is given 
to the requested segment or returned to the 
calling segment, depending on the type of 
invoking instruction (SEGLD, SEGWT, CALL, 
or branch). See Figures 4-7 and 4-9. 



FETCHING ROUTINES AND MODULES TO MAIN 
STORAGE 

The Program Fetch routine loads SVC rou- 
tines, I/O error-handling routines, and 
other modules. As part of the loading pro- 
cess, the Program Fetch routine obtains 
needed storage space, performs I/O opera- 
tions, and relocates address constants when 
necessary. 

The Program Fetch routine is invoked, 
via a branch instruction, by any of several 
supervisor routines, depending on the type 
of module or routine that is requested, as 
follows: 



h- 



Type of Requested 
Module or Routine 



-■ I- 



Nonresident SVC routine 



I/O error handling routine 



Nonoverlay module that 
is not available in main 
storage, or the root seg- 
ment of an overlay module 
that is not available in 
main storage 

A segment of an overlay 
module (except the root 
segment) 



Routine 
That Invokes 
Program Fetch 



Transient Area 
Fetch routine 

Stage 3 

Exit Effector 

Common sub- 
routines of 
Contents 
Supervision 



Overlay 
Supervisor 
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r T 

I Conditions | 

^ + 

1. Requested segment is in main 
storage. (indicator 10) 



Resultant Processing by lEWSZOVR 



2. 



If entry is for a SEGWT or SEGLD request, control 
is returned to caller. If entry is for CALL or 
branch, ENTAB entries are altered to provide future 
branch entry to segment. 



Requested segment is not in 
main storage. (indicator 11) 



Sets indicator to show "loading scheduled" (01) and 
continues to scan. 

Determines if the preceding entry is for a segment 
in the path of the requested segment. 



3. The preceding entry is for 
a segment in the path of the 
requested segment. 
I 



Checks status indicator of preceding entry to 
determine if its segment is in main storage. (Next 
step is 5 or 6.) 



U. The preceding entry is for a 
segment not in the path of 
the requested segment. 



H- 



Sets status indicator of preceding entry to "not in 
main storage" (11) in preparation for overlaying 
the segment. Continues scan. 



5. Preceding entry is for a seg- 
ment in the path, and indi- 
cates its segment is in main 
storage. 



Scan is stopped. The ass\amption is that all seg- 
ments in the path of the requeted segment are in 
main storage (except the requested segment itself). 



Preceding entry is for a seg- 
ment in the path, and indi- 
cates its segment is not in 
main storage. 



, 

Sets the status indicator of the entry whose segment 
is in the path to "loading scheduled" (01) and 
continues the scan. 



Figure 4-11. Processing of Segment Table Entries 



Fetching SVC and I/O Error-Handling 
Routines 

Either the SVC Second-Level Interruption 
Handler or the Stage 3 Exit Effector deter- 
mines if a usable copy of the desired rou- 
tine is in a transient area block (TAB) of 
main storage. If a usable copy is in a 
TAB, control is given to the routine. 
Otherwise, the Program Fetch routine is 
invoked to load the recpiested routine into 
a TAB. A nonresident SVC routine is placed 
in an SVC transient area block; an I/O 
error-handling routine is placed in the I/O 
Supervisor transient area block (see Figure 
i»-12). 

If the Program Fetch routine must be 
invoked, the caller places in a fetch work 
area the relative disk address and the size 
of the routine to be loaded. The caller 
obtains this information from the data-set 
directory entry belonging to the SYSl. 
SVCLIB data set. 



Note ; A separate fetch work area precedes 
each transient area block. Each work area 
contains 68 bytes of space and is con- 
structed during system generation. (See 
"Program Fetch Work Area" in Section 12.) 
The work area contains an input/output 
block (lOB), an event control block (ECB) , 
and a channel program. (See Figure 4-13.) 



The Program Fetch routine determines the 
absolute disk address of the requested rou- 
tine and causes the loading of the routine. 
It converts the relative disk address of 
the routine to an absolute address by means 
of a resident "convert" routine. It then 
issues an EXCP macro instruction and a WAIT 
macro instruction. The EXCP macro instruc- 
tion causes the I/O Supervisor to be 
invoked to fetch the desired routine from 
the SYSl. SVCLIB data set to the appropriate 
TAB. The routine's entry point address is 
the same as the address of the TAB. No 
relocation is needed, since a transient SVC 
routine contains no relocatable address 
constants . 

When the requested routine has been 
loaded, the Program Fetch routine checks 
for I/O errors, places a return code in 
register 15 to indicate that the fetch has 
been successful or that I/O error or inval- 
id information has been detected, and 
returns control to the calling routine. 

Fetching Nonresident Modules 

The Program Fetch routine is invoked 
either by the common subroutines of Con- 
tents Supervision or by the Overlay 
Supervisor. 

It is invoked by the common subroutines 
of contents Supervision after a LINK, 
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Figure t-12. Relationships of Program Fetch Routine to Other Routines for the Fetch of 
an SVC Routine or an I/O Error Routine 



ATTACH, LOAD, or XCTL macro instruction has 
been issued, if a usable copy of the needed 
module is not in main storage. It is 
invoked by the Overlay Supervisor after a 
SEGWT, SEGLD, or CALL macro instruction, or 
a branch instruction has been issued, if 
the needed segment of an overlay module is 
not in main storage. The relationship of 
the Program Fetch routine to other routines 
for the fetch of a module or overlay seg- 
ment is depicted in Figure 4-11. 



The major functions of the Program Fetch 
routine for the loading of a nonresident 
module or an overlay segment are: 

Initialization 

initializes a fetch work area, builds 
an extent list, and (if the module is 
in overlay mode) fetches the module's 
note list. If the module is to be 



scatter- loaded, the routine fetches 
the scatter/translation table. 

Loading 

transfers text records and relocation 
list dictionary (RLD) records from 
auxiliary storage to main storage. 
The text records constitute the pro- 
gram that is loaded. The RLD records 
are used for relocation. 

Relocation 

changes the values of address con- 
stants in the loaded program from 
relative addresses to absolute 
addresses. 

Termination 

checks the completion of I/O opera- 
tions, calculates the relocated module 
entry-point address, initializes the 
segments table (if the module is in 
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overlay mode) , sets up a return code, 
and returns control to the caller. 



INITIALIZATION ; The Program Fetch routine 
can make available three areas or tables 
for later use- They are the program fetch 
work area, the extent list, and the note 
list. The fetch work area is used by the 
Program Fetch routine to load module re- 
cords. The extent list is used by the com- 
mon subroutines of Contents Supervision to 
prepare linkage to the module; it is used 
by the CDEXIT routine to free the module's 
storage areas during end-of-task and 
abnormal termination procedures. The note 
list is part of an overlay module; it con- 
tains the relative disk address of each 
segment and, after main storage has been 
obtained, contains the module's relocation 
factor. 

Initializing the Fetch Work Area ; The Pro- 
gram Fetch routine initializes a work area 
whose address is furnished by the caller. 
It places in the work area information that 
it will use to load the requested module. 
This information consists of; 
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Figure U-13. 



Control Blocks and Tables 
Used by the Program Fetch 
Routine 



• An input/output block (lOB) . The lOB 
provides information that is needed by 
the I/O Supervisor. 

• Two event control blocks (ECBs) . One 
ECB is posted by the I/O Supervisor 
when a channel-end condition occurs. 
The other is posted by a PCI Appendage 
routine when a program-controlled 
interruption occurs in a channel pro- 
gram. The posting of either ECB per- 
mits the restarting of the Program 
Fetch routine after an I/O wait 
interval. 

• Three channel programs . The channel 
programs are similar. They are used to 
overlap the reading of one or more 
module records with the relocation of 
address constants pointed to by a pre- 
viously loaded RLD record. 

• Three RLD buffers . Each buffer is 260 
bytes in length, and is capable of 
holding an RLD record, a control rec- 
ord, or a composite control and RLD 
record. 

• A buffer table . This table contains a 
12-byte entry for each RLD buffer. 
Each entry contains: 

• A pointer to the next entry. 

• The address of an RLD buffer. 

• The address of a channel program. 

Building an Extent List ; The extent list, 
when completed, contains the main storage 
address and length of each loadable section 
of a module (see Figure 4-15) . The size of 
the extent list and the procedures for con- 
structing it depend on whether the module 
is to be block-loaded or scatter-loaded. 
During the construction of the extent list, 
main storage is obtained in preparation for 
loading the module. 

If the module is to be block- loaded, the 
Program Fetch routine obtains space for an 
extent list, and if necessary, a note list. 
The routine places in the "length" field of 
the extent list the total size of the 
module, as shown in the data-set directory 
entry. Next, the Program Fetch routine 
issues a GETMAIN macro instruction to 
obtain space for the module. The assigned 
main storage address returned by the GET- 
MAIN routine is then placed in the address 
field of the extent list. 

In systems generated with storage 
hierarchies, a GETMAIN request is issued 
for the creation of the block extent list, 
followed by an unconditional GETMAIN re- 
quest using the specified hierarchy. If no 
hierarchy is specified, the request is 
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Figure 4-14. Relationship of Program Fetch Routine to Other Routines for the Fetch of a 
Module or Overlay Segment 



satisfied from hierarchy 0. If the uncon- 
ditional request made by Program Fetch can- 
not be f infilled, the GETMAIN routine 
determines whether to invoke ABEND or 
Rollout/Rollin functions. 



If the module is to be scatter-loaded, 
the Program Fetch routine builds an extent 
list and obtains space for the module, as 
follows : 

1. Determines the needed space for the 
extent list. It does this by calcu- 
lating the size of the scatter list/ 
translation table from information 
contained in the data-set directory 
entry. The scatter list and transla- 
tion table are placed by the Linkage 
Editor in a module that can be 
scatter-loaded (see Linkage Editor 
PLM). 



I No. of Bytes in Extent List 
^ 

I No. of Relocation Factors 



(Length of First Storage Block 



I Address of Last storage Block 
I 

Figure 4-15. Extent List 
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Issues a GETMAIN macro instruction for 
space for the combined extent list and 
scatter list/translation table. 

Obtains the relative disk address of 
the first scatter list/translation 
table record from the data-set direc- 
tory entry and converts it to an abso- 
lute disk address. The routine 
obtains the size of the scatter list/ 
translation table from the data- set 
directory entry. It then issues an 
EXCP macro instruction to read the 
record(s). The scatter list/ 
translation record (s) are read from 
auxiliary storage to the lower part of 
the space allocated to the extent 
list. 

Initializes the extent list with the 
length of the extent list itself, the 
number of scatterable control sec- 
tions, and the length of each control 
section of the module. The routine 
determines the length of the extent 
list from the number of entries in the 
scatter list. It calculates the 
length of each control section from 
the relative addresses of the control 
sections, recorded in the scatter 
list/translation table. 

Obtains space for each control section 
by the issuance of a GETMAIN macro 
instruction that specifies the list of 
control-section lengths just calcu- 
lated (step 4). The GETMAIN routine 
returns to the Program Fetch routine 
the allocated address for each control 
section. 



designators reference the same hierarchy, 
an attempt is made to block load the 
module. If this is unsuccessful. Program 
Fetch builds a list of lengths for each 
CSECT and an unconditional GETMAIN request 
is issued for the proper hierarchy. 

When the scatter list/translation table 
record indicates that the module had been 
link edited to utilize multiple hierar- 
chies. Program Fetch builds a list of 
lengths for each CSECT and appends the 
appropriate hierarchy designator to each 
CSECT. An unconditional GETMAIN request is 
then issued and space is obtained from both 
hierarchies and 1. 

Obtaining the Note List ; If the module to 
be loaded is in overlay mode, the Program 
Fetch routine must load the note list 
before it fetches the root segment of the 
module. The note list, placed in an over- 
lay module, by the linkage editor, contains 
the relative disk address (TTR) of each 
segment of the module. When the root seg- 
ment has been loaded, the Program Fetch 
routine stores in the note list the address 
of the segment table (SEGTAB), and the 
relocation factor for the module. The note 
list remains in main storage throughout the 
module's execution. (See Figure U-16.) 

To load the note list, the Program Fetch 
routine follows a procedure similar to that 
just described in steps 1, 2, and 3 in 
"Building an Extent List. " 

LOADING OF MODULE RECORDS ; The program 
Fetch routine loads module records of sev- 



6. Calculates the relocated address for 
each control section from its allo- 
cated address (obtained from the GET- 
MAIN routine) and its relative address 
(obtained from the scatter list/ 
translation table) . 

When a request is made for a specific 
hierarchy, a conditional GETMAIN request is 
issued for the specified hierarchy. If 
sufficient contiguous storage is not avail- 
able. Program Fetch builds a list of 
lengths in preparation for the scatter 
attempt for each CSECT. The GETMAIN re- 
quest is then issued for the specified 
hierarchy. 

If the request is made without specify- 
ing a hierarchy in a system generated with 
storage hierarchies, initiation for hierar- 
chy loading is performed. The size of the 
extent list for scatter and the size of the 
scatter list/translation table record are 
determined before the GETMAIN request is 
issued. The scatter list/translation table 
record is processed to determine the link- 
age editor hierarchy designator. If all 



r T ^ 

I I Relocation factor for module | 
^ X T__ 1 

I I Concatenation | 

I I Number | 

^ X ^ 

I TTR - relative (to beginning of data | 
I set) disk address of segment 1 j 

^ _ ^ 

|TRR - relative (to beginning of data | 
I set) disk address of segment 2 j 

L 1 

• • 

r 1 

I TTR - relative (to beginning of data | 
jset) disk address of segment N j 

L I 

Note ; concatenation Number - This is 
a value specifying this data set's 
sequential position within a group of 
concatenated data sets. 



Figure 4-16. Note List as it Exists in 
Main Storage 
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eral types: control records, text records, 
RLD records, and composite control/RLD re- 
cords. A typical logical sequence is shovm 
in Figure 4-17. Their formats are 
described in Section 12, "Control Blocks 
and Tables." (For a discussion of each 
type, see the Linkage Editor PLM . ) 

The loading of module records consists 
broadly of four functions: 

• Preparing for the execution of a chan- 
nel program . An absolute disk seek 
address is computed and made available 
to the I/O Supervisor. 

• Starting a channel program . The I/O 
Supervisor is invoked to start the I/O 
operation at the specified disk 
address. 

• Reading of module records . Text and 
RLD or control records are read to main 
storage blocks or to buffers. 

• Switching of channel programs . Three 
channel programs are switched to follow 
the sequence of module records on the 
direct access device. 

Preparing for Execution of a Channel Pro- 
gram ; The Program Fetch routine, to obtain 
the execution of a channel program, must 
furnish to the I/O Supervisor an atjsolute 
disk address at which the first I/O opera- 
tion will begin. The routine accomplishes 
this objective by: 

• Obtaining the relative track and record 
address (TTR) of the first text record 
from the data set directory entry, or 
obtaining the TTR of the needed segment 
from the note list. 

• Converting the relative address to an 
absolute address, via a branch to a 
"convert" routine that is resident in 
the nucleus. 

• Placing the absolute disk seek address 
in the program fetch input/output block 
(lOB) , for later use by the I/O 
Supervisor. 

Starting a Channel Program ; The Program 
Fetch routine starts a channel progrcim by 
issuing an EXCP macro instruction to obtain 



supervisor linkage to the I/O Supervisor. 
The lOB address is provided as an operand 
of the macro instruction. 



The EXCP Supervisor, part of the I/O 
Supervisor, obtains control from the I/O 
First-Level Interruption Handler (I/O 
FLIH) . The EXCP Supervisor issues a Start 
I/O instruction for a Stand-Alone Seek com- 
mand. The Stand-Alone Seek command moves 
the access arm of the direct access device 
to the seek address contained in the lOB. 
The I/O Supervisor, via a Transfer in Chan- 
nel command, then passes control to a fetch 
channel program, whose address the Program 
Fetch routine placed in its lOB. The fetch 
channel program causes the first text rec- 
ord to be read into main storage, beginning 
at the first assigned main storage address 
contained in the extent list. 

After the channel program has been 
started, the I/O Supervisor returns control 
to the Program Fetch routine to await post- 
ing of an event control block by the I/O 
Supervisor or an appendage routine. Such 
posting indicates that one or two records 
have been read and that further processing 
can occur in the Program Fetch routine. 



Reading of Module Records : The channel 
program causes the reading of two records, 
a text record and an RLD or control record, 
if the RLD or control record follows the 
text record. The text record is placed in 
its appropriate block of main storage. The 
RLD or control record is placed in an RLD 
buffer. 



Switching of Channel Programs : If an RLD 
and control record, or a control record 
alone, does not follow a text record, con- 
trol must be passed to another channel pro- 
gram to read a single record. The record 
must then be tested for control informa- 
tion. The Program Fetch PCI Appendage rou- 
tine tests a record in the current RLD 
buffer and, when necessary, causes a 
channel-program switph between two-record 
mode and single-record mode. The PCI 
Appendage routine obtains control from the 
I/O Supervisor during the execution of any 
of the three fetch channel programs. (For 
overall control flow, see Figure 4-18.) 



r 1 r 1 r 1 i 1 r 1 r 1 r 1 

I Record 1 | | Record 2 | [Record 3 | | Record 4 | | Record 5 | | Record 6 | | Record 7 | 

I control I I Text | | Control | | Text j | RLD | | Control-RLD- | | Text | 

I II II II II I |End-of-Seg. | | | 

j 20 bytes j |500 bytes j 120 bytes j |1024 bytes j |260 bytes | j 200 bytes j | 15 bytes j 

Figure 4-17. Typical Load-Module Logical Format on Direct Access Device 
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Figure U-18. Overall Control Flow During the Loading of a Module or Segment 
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conditions 



1. 



Resultant Processing by PCI Appendage Routine 



2. 



The next RLD buffer is 
filled (busy). 



Indicates in buffer table that all buffers are filled 
("busy"). Does not alter current channel program, which 
continues in execution. Performs Step 7. 



The last record (in 
current buffer) was 
either an RLD and 
control record, or a 
control record alone. 



. The last record was 
not an RLD record. 



Initializes the next channel program to read a pair of 
records, starting with a text record. Alters the No- 
Operation (NOP) command in the current channel program to 
transfer-in-channel (TIC) to the next channel program to 
read a pair of records. Tests the last record (control 
information) to determine if the next text record is the 
last text record of the module or segment. (See Step 6.) 



1— 

H. 



An extent boundary was 
crossed on the direct 
access device. 



If the entire module or segment has not been loaded (see 
Step 5) , alters the NOP command in the current channel 
program to transfer-in-channel (TIC) to the next channel 
program to read a single RLD or control record. Performs 
Step 7. 

1 



Obtains from the data extent block for the library the 
initial extent boundary for the next part of the module. 
Places the extent boundary into the appropriate unit con- 
trol block. Computes new absolute seek address and places 
it in the lOBSEEK field of the lOB. These actions are in 
preparation for the issuance of another EXCP macro 
instruction. 



The entire module 
segment has been 
loaded. 



or 



5. Sets appropriate "end" flag and performs Step 7. 



I— 



The next text record 
is the last text 
record of the module 
or segment (as indi- 
cated by the end-of- 
segment (BOS) or end- 
of-module (EOM) flag 
in the previous 
control record) . 



Prepares for the reading of a single text record by clear- 
ing the command chaining flag in the First Read Channel 
command word of the next channel program. 



Processing described 
in Step 1, 3, or 5 has 
been performed. 



Posts the fetch event control block (ECB) to prepare the 
Program Fetch routine for restart by the Dispatcher. Re- 
start occurs at the instruction after the WAIT macro 
instruction. 

Figure 1-19. Channel-Program Switching After a Program-Controlled Interruption 



A channel command word in each channel 
program causes a program- controlled inter- 
ruption (PCI) . The PCI (a type of I/O 
interruption) causes supervisor linkage to 
the I/O Supervisor, which determines the 
cause of the interruption, and branches to 
the PCI Appendage routine. The PCI Appen- 
dage routine tests the buffer table and the 
current RLD buffer to determine the 
channel-program switching that is required. 
The processing that results from these 
tests is described in Figure 4-19. 

The I/O Supervisor processes a channel- 
end interruption, if the No-Operation com- 
mand in a channel program is not altered 
before the channel program finishes. The 
I/O Supervisor gives control to the Program 



Fetch channel- End Appendage routine. This 
routine tests if the entire module or seg- 
ment has been loaded. 

If the entire module or segment has been 
loaded, the Channel- End Appendage routine 
returns control to the I/O Supervisor to 
post the I/O event control block (ECB) , in 
preparation for the restarting of the Pro- 
gram Fetch routine. Control is passed from 
the I/O Supervisor to the Program Fetch 
routine, via the I/O First-Level Interrup- 
tion Handler and the Dispatcher (see Figure 
t-13). The Program Fetch routine then per- 
forms termination procedures. 

If, however, the entire module or seg- 
ment has not been loaded, the Channel-End 
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Appendage routine returns control to the 
I/O Supervisor to restart the channel 
program . 

RELOCATING ADDRESS CONSTANTS IN RELOCATION 
LIST DICTIONARY CRLD) RECORDS ; The Program 
Fetch routine is restarted after the PCI 
Appendage routine or the I/O Supein^isor has 
posted an ECB. The Relocation subroutine 
of the Program Fetch routine then examines 
the buffer table to determine whether an 
RLD record, containing relocatable address 
constants, is in an RLD buffer. The sub- 
routine searches for a buffer table entry 
whose "busy" indicator is set. The indica- 
tion means that the associated buffer con- 
tains an RLD record. When such a buffer is 
found, the Relocation subroutine relocates 
each address constant specified in the rec- 
ord. When RLD records in all "busy" buf- 
fers have been processed, the Program Fetch 
routine either restarts a channel program, 
if a buffer is empty, or issues a WAIT 
macro instruction to await the loading of 
another record. 

The Relocation subroutine adjusts the 
value of an address constant by combining 
(adding or subtracting) a relocation factor 
with the value of the constant. Each RLD 
record contains the linkage-editor assigned 
address of the constant and a flag that 
indicates addition or subtraction of the 
relocation factor. (See "Relocation List 
Dictionary Record" in Section 12, "Control 
Blocks and Tables.") 

For a block- loaded module, the reloca- 
tion factor is the difference between its 
linkage-editor assigned address (usually 
zero) and the first byte of main storage 
into which the module has been loaded. The 
relocation factor is either added to or 
subtracted from the value field of each 
relocatable address constant. As an 
example, assume that a module is block- 
loaded into main storage, beginning at 
address 4000. If the flag bit in the RLD 
record is positive, a relocation factor of 
4000 is added to the value field of each 
address constant. If, however, the flag 
bit in the RLD record is negative, 4000 is 
subtracted from the value field of the 
constant . 

For an overlay module, relocation is 
similar to that just described, since an 
overlay module is effectively block-loaded. 
The root segment's relocation factor is 
used to adjust the address constants of all 
segments of the module. The Program Fetch 
]X)utine stores the relocation factor in the 
note list, so that it is available in main 
storage throughout the module's execution 
(see Figure 4-16) . 

For a scatter- loaded module, each entry 
of an RLD record contains the linkage- 



editor assigned address of an address con- 
stant, a relocation pointer, and a position 
pointer. The position pointer is used to 
locate the address constant. The reloca- 
tion pointer is used to find the relocation 
factor by which the address constant will 
be adjusted. 

The position pointer is used to index 
the translation table to obtain a value 
that indicates the control section in which 
the address constant is located. The tran- 
slation table value is then used to obtain 
a relocation factor from the scatter list. 
The relocation factor, when combined with 
the linkage- editor assigned address of the 
constant, yields the location of the 
address constant. (For more information on 
the translation table and scatter list, see 
the Linkage Editor PLM . ) 

The relocation pointer is similarly used 
as an index to obtain the relocation factor 
for the control section to which the 
address constant refers. This relocation 
factor is combined with the linkage-editor 
assigned value of the constant. The resul- 
tant relocated value is then placed in the 
value field of the constant. 



TERMINATION: 



If the control record before 



the last text record contains an "end" 
indicator, the PCI Appendage routine sets 
an "end" flag to inform the Termination 
subroutine. After relocation has been per- 
formed, a test of the "end" flag causes the 
subroutine to be entered. 

The Termination subroutine performs its 
processing or waits, according to whether 
all I/O operations have been completed. 
When all I/O operations have been com- 
pleted, the subroutine places a completion 
code in the return register. The comple- 
tion code informs the caller of the result 
of the attempted loading (see Figure 4-20). 

The rest of the termination procedure 
depends on the type of module that has been 
loaded (see Figure 4-21) . When termination 
is complete, the Program Fetch routine 
returns control to the caller. 



r r 1 

I Code I Meaning | 

Successful Load 



X'OO' 
X'OC 
X'OD' 
X'OE' 
X'OF" 



Invalid Scatter Information 
Invalid Record Type 
Invalid Address Encountered 
Permanent I/O Error 



Figure 4-20. Program Fetch Return Codes 
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JType of Module 



I Processing by the Program Fetch Routine | 

+ _ _ ___^ 

Computes relocated entry-point address for the module, and places 
it in the fetch parameter list for use by the caller. 



j Block- loaded module 
I 



j Scatter- loaded 
(module 



JRoot segment of 
I overlay module 



Computes the relocation factor for the entry-point address and 
places it in the fetch parameter list. The subroutines of Con- 
tents Supervision use this relocation factor to compute relocated 
entry-point addresses. Frees the space occupied by the scatter 
list/translation table. 



L 



Places in the segment table the main storage address of the data 
control block (DCB) and of the note list for use by the Overlay 
Supervisor . 



X 



J 



Figure '»-21. Termination Processing According to Module Type 
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SECTION 5 : MAIN STORAGE SUPERVISION 



Main storage space is a resource and, 
like other resources, is shared by many 
users. Allocation of space must be con- 
trolled, and space must be requested when 
it is needed and be freed when it is no 
longer needed. Control over space alloca- 
tion is exercised by the routines of Main 
Storage Supervision and by the routines of 
the optional rollin/rollout module. The 
Main Storage Supervision routines service 
two macro instructions: GETMAIN, which is 
used to allocate space; and FREEMAIN, which 
is used to free space that was previously 
allocated. Each macro instruction results 
in an SVC interruption and entry to a 
corresponding service routine. 

Requests for allocation of main storage 
space are serviced by Main Storage Supervi- 
sion elements collectively called the 
GETMAIN routine. This routine services all 
reqpaests for space, including requests for 
a region, space within an existing region, 
or space in the system queue area. By 
keeping and continually updating control 
blocks that record where space is avail- 
able, the GETMAIN routine can determine 
where and how a request may be satisfied. 

Requests to free main storage space are 
serviced by Main Storage Supervision ele- 
ments collectively called the FREEMAIN rou- 
tine. This routine updates control blocks 
to reflect the change of status of the 
freed space, thereby making the space 
available for reallocation by the GETMAIN 
routine. 

An unconditional request for the alloca- 
tion of main storage space in an existing 
region, if unsatisfied by the GETMAIN rou- 
tine, can cause the GETMAIN routine to 
schedule linkage to the rollout/rollin 
module. This extra effort to obtain the 
requested space is possible if the rollout 
feature is included in the system and if 
the recpiester belongs to a job step eligi- 
ble to cause rollout. The rollout/rollin 
module is not scheduled if the requester is 
a system routine, if the request is for 
space in the system queue area, or if the 
request is for a region in which to start a 
new job step. 

The rollout/rollin module, when executed 
for the GETMAIN routine, tries to obtain a 
temporary additional region for use by the 
requester's task and other tasks of its job 
step. This is necessary since the request- 
ing job step needs more space than is 
available in its existing region. The 
rollout/rollin module first tries to allo- 



cate the temporary region from unassigned 
space in the dynamic area. If sufficient 
unassigned space is not available, the 
rollout/rollin module then searches for a 
suitable job step of another job that it 
may roll out. A job step is suitable to be 
rolled out if its dispatching priority is 
lower than that of the requester's job 
step, its job step TCB is flagged eligible 
to be rolled out, and if it is not using or 
waiting for a system resource for which it 
has issued an ENQ macro instruction. 



If the rollout/rollin module finds a 
suitable job step whose region is large 
enough to satisfy the current request, it 
waits for completion of active I/O com- 
mands, suspends pending I/O commands, 
defers pending operator replies, and trans- 
fers (rolls out) to auxiliary storage the 
contents of the selected job step's region. 
It then builds and initializes control 
blocks to allocate the rolled out region to 
the requester's job step. The rollout/ 
rollin module returns control to the requ- 
ester, which reissues its original GETMAIN 
macro instruction, causing supervisor link- 
age to the GETMAIN routine. The GETMAIN 
routine then services the request from the 
region just obtained through rollout. 



At key decision points in the rollout 
processing there are dummy user routines 
which the user may replace with his own 
optional appendages. The user^ written 
appendages may do the following: 

• Determine whether more than one job 
step can concurrently obtain space 
through rollout of other job steps' 
regions. Such an option is called 
"multiple rollouts." 

• Decide whether a region belonging to a 
job step of higher dispatching priority 
than the requester's job step should be 
rolled out. 

• Decide if a job step should be abnor- 
mally terminated, if there is no job 
step suitable to be rolled out. 
Abnormal termination could be selected 
in place of the standard alternative of 
placing the requester's job step on a 
wait queue, pending a new attempt at 
rollout . 

• Specify additional criteria that must 
be met by a job step before it can be 
rolled out. 
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After the requester's job step has com- 
pleted its use of the borrowed region (sig- 
naled by issuance of a FREEMAIN macro 
instruction) , the FREEMAIN routine sched- 
ules linkage to the rollout/ rollin module. 
This time the module transfers (rolls in) 
the contents of the rolled out job step's 
region from auxiliary storage to its origi- 
nally assigned location in main storage. 
Deferred I/O commands and deferred opetator 
replies are then restored to the job step. 
The rollout/rollin module returns control 
to t.he current routine of the highest 
priority ready task, via the Exit routine 
and the Dispatcher. 



INTERRUPTION HANDLING FOR MAIN STORAGE 
SUPERVISION 

Both the GETMAIN and FREEMAIN macro 
instructions may be expressed by program- 
mers in two forms. S (storage) type macro 
instructions are used when parameters are 
supplied in a parameter list, and R 
(register) type macro instructions are used 
when parameters are supplied in general 
registers. Figure 5-1 shows the SVC 
instructions contained in expansions for 
each type. 

When any SVC instruction is executed, an 
SVC interruption occurs and control is 
given to the SVC First-Level Interruption 
Handler, which saves a record of the inter- 
rupted environment and routes control to an 
appropriate SVC service routine. A 
description of SVC first- level interruption 
handling is contained in the section "SVC 
Interruption Handling". Figure 5-2 shows 
the handling of interruptions resulting 
from issuance of GETMAIN and FREEMAIN macro 
in struct ions . 

For SVC U and SVC 5 instructions, the 
SVC First-Level Interruption Handler gives 
control to the GETMAIN and FREEMAIN rou- 
tines, respectively. For SVC 10 instruc- 
tions, it gives control to the REGMAIN rou- 
tine, which examines register 1 to deter- 
mine whether a GETMAIN or FREEMAIN macro 
instruction was given, and routes control 
accordingly. 



SVC interruption 



I Macro Instruction! Type jSVC Instruction] 
+ ^ ^ 

GETMAIN I S I SVC H 
I R I SVC 10* 
I + + ^ 



FREEMAIN 



SVC 5 
SVC 10* 



X J. . J 



♦High-order bit of register 1 will con- 
tain 1 for GETMAIN; for FREEMAIN. 



L 





SVC 

First-Level 
Interruption 
Handler 












Type 1 SVC 
Routine 






SVC 4 




] SVC 10 




j SVC 5 


GETMAIN 
Routine 




REGMAIN 
Routine 






FREEMAIN 
Routine 




























' 










Type 1 Exit 
Routine 








Current routine 
of higliest 
priority tasl< 
that can be 
performed 



Figure 5-2. 



Main Storage Supervision 
Interruption Handling 



Figure 5-1. 



GETMAIN/FREEMAIN SVC 
Instructions 



The GETMAIN, FREEMAIN, and REGMAIN rou- 
tines are type 1 SVC routines. After the 
GETMAIN and FREEMAIN routines have com- 
pleted their processing, they give control 
to the Type-1 Exit routine. The Type-1 
Exit routine determines whether the task 
for which the SVC instruction was executed 
is to be reinstated. If so, it restores 
the saved contents of registers and returns 
control to the routine in which the SVC 
instruction was encountered. If, however, 
a different task is to gain control, the 
Type-1 Exit routine saves register contents 
in the current TCB, saves the SVC old PSW 
in the current request block, and branches 
to the Dispatcher. The Dispatcher routes 
control to the current routine of the high- 
est priority ready task. 



ALLOCATING MAIN STORAGE 

All requests for space are handled by 
the GETMAIN routine. These include 
requests for regions, space within regions, 
and space in the supervisor queue area of 
main storage. Basically, the GETMAIN rou- 
tine scans queues of elements that repre- 
sent available space to locate the amount 
of space of the type requested. When the 
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space is found, the GETMAIN routine updates 
the affected queues to reflect its subse- 
quent unavailability and returns the 
address of the space to the requester. If 
the requested space is not available, the 
GETMAIN routine responds according to the 
type of storage that is requested: a new 
region, space within an existing region, 
space in the system queue area, or space in 
the local system queue area. 

If requested space for a new region is 
not available, and the request is condi- 
tional, the GETMAIN routine sets up a 
return code and returns control to the re- 
quester, via the Type-1 Exit routine. If, 
however, the request is unconditional, the 
GETMAIN routine makes the requester's task 
nondispatchable, pending the availability 
of sufficient free space in the dynamic 
area, and causes control to be given to the 
current routine of the highest priority 
ready task. 



If requested space within an existing 
region is not available, the GETMAIN rou- 
tine tries to find space that may be freed 
and allocated to the requester's task- It 
first searches for unused modules in the 
requester's region that may be purged. If 
sufficient space cannot be made available 
by the module purge, and the request is 
conditional, the GETMAIN routine sets up a 
return code and returns control to the re- 
quester, via the Type-1 Exit routine. If, 
however, the request is unconditional, and 
if the rollout feature cannot be used, the 
GETMAIN routine causes the abnormal ter- 
mination of the requester's task. If, 
however, the rollout feature is part of the 
system and the requester's task is eligible 
to cause rollout, the GETMAIN routine 
schedules linkage to the rollout/rollin 
module. The rollout/rollin module tries to 
obtain temporary allocation of an addition- 
al region for use by the requester's job 
step. The additional region may be 
obtained either from free space in the 
dynamic area or by temporary reallocation 
of a region previously allocated to a job 
step of another job. If the rollout/rollin 
module cannot find the needed region, it 
either causes the abnormal termination of 
the requester's job step or another job 
step, or makes the requester's job step 
temporarily nondispatchable pending the 
availability of the needed region. The 
choice depends on the option specified in a 
user-written appendage. 



If the requested space in the system 
queue area is not available, the GETMAIN 
routine purges and frees CDEs within the 
system queue area. If this does not make 
sufficient system queue area available, the 
GETMAIN routine attempts to expand the sys- 



tem queue area by assigning to it 2K blocks 
of adjacent free dynamic area storage. If 
the system queue area cannot be expanded 
(because the adjacent dynamic area is 
assigned to a region) , or if the system 
queue area is expanded but still cannot 
satisfy the request, the GETMAIN routine 
determines if 144 bytes of system queue 
area are available. If not, the GETMAIN 
routine places a completion code of E04 in 
the TCB of the requester, sets the TCB non- 
dispatchable, and causes the CPU to be 
placed in an enabled wait state with a wait 
code of E04. If 144 bytes of system queue 
area are available, the GETMAIN routine 
uses ABTERM to schedule the requester for 
abnormal termination with a completion code 
of E04. The 144 bytes are necessary to 
build the SVRB for ABEND which terminate 
the requester. In a Model 65 Multiproces- 
sing System, if the system queue area is 
expanded, the new size and origin of the 
dynamic area is placed in the PQE- 

If requested space in LSQA is not avail- 
able, the GETMAIN routine causes abnormal 
termination of the requester's task unless 
the task is already in abnormal termination 
processing. In this case, the request is 
changed to a request for space in SQA. 

Following entry to the GETMAIN routine, 
the Subpool Check (CSPCHK) subroutine is 
entered to determine what type of space is 
requested. Figure 5-3 shows the subpool 
numbers associated with each type of 
request. 



ALLOCATING A REGION 

Space for regions is obtained from the 
dynamic area of main storage (see Figure 
5-4). The PQEPTR field at offset 8 in 
location GOVRFLB contains the address of a 
two- word dummy partition queue element 
(DPQE) less 8 bytes. Word one of the DPQE 
contains the address of a partition queue 
element (PQE) that describes unassigned 
processor storage not assigned to any 
region. Word two of the DPQE contains the 
address of the last PQE constructed by NIP. 

In a system with Main Storage Hierarchy 
Support, word three of the PQE for hierar- 
chy contains the address of the PQE that 
describes unassigned IBM 2361 Core Storage 
not belonging to any region. If IBM 2361 
Core Storage was off-line at IPL, this word 
contains zeros and any requests for hierar- 
chy 1 storage are logically satisfied from 
processor storage. If Main Storage Hierar- 
chy Support is not included in the system, 
or if Main Storage Hierarchy Support is 
included but IBM 2361 Core Storage is not 
on-line at IPL, only one PQE, describing 
allocatable storage, is constructed. 
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Figure 5-3. Subpool Numbers Used for Requesting Space 
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Element Relationships: 
Region Allocation 



Words one and two of the PQE point to 
the first and last, respectively, free 
block queue elements (FBQEs) associated 
with the area of storage described by the 
PQE. FBQEs occupy the first three words of 
each free block of each type of storage and 
contain a count of the number of free bytes 
available in that block of storage. FBQEs 
are forward and backward chained in address 
order so that main storage supervision rou- 
tines may scan them from either high to low 
address or low to high address. 



To assign a region, the GETMAIN routine 
searches for the highest block of free 
storage in the dynamic area that is large 
enough to satisfy the request. It then 
determines the beginning address of the 
region : 



Beginning = the size of Free Block of 
Address storage + the address of the 
FBQE (for that block of free 
storage) - the size of Region 
Requested 



The GETMAIN routine then subtracts the 
number of bytes to be occupied by the 
region from the number of bytes in the FBQE 
that represents the block of free storage. 



For each region, the GETMAIN routine 
builds a free block queue element (FBQE) at 
the beginning of the region and a dummy 
partition queue element and a partition 
queue element (PQE) in the system queue 
area (see Figure 5-4). The GETMAIN routine 
places in the free block queue element a 
count of the number of contiguous free 
bytes that can be allocated in the region. 
The dummy partition queue element is made 
to point to the partition queue element, 
which in turn is given a pointer to the 
free block queue element. The GETMAIN rou- 
tine places in the PQE the size of the 
region and the region address. It places 
the address of the dummy PQE less 8 bytes 
in the TCBPQE field of the TCB of the job 
step task for which the region was 
requested. If Main Storage Hierarchy Sup- 
port is included in the system, regions may 
be requested in either hierarchy, or a 
region may be requested with segments in 
both hierarchies. A PQE is constructed for 
each region segment and both PQEs are 
chained (by way of a dummy PQE) to the TCB 
that represents the task for which the 
region was requested. (For the formats of 
the dummy PQE, PQE, and FBQE, see Section 
12, "Control Blocks and Tables.") 



The GETMAIN routines additionally sup- 
port obtaining a region at a specific 
storage address and quiescing the system if 
a valid request for a region at a specific 
address cannot be satisfied. 



The function of obtaining a region is 
performed by the GETPART module, invoked by 
expansion of the GETMAIN macro instruction. 

To obtain a region at a specific main 
storage address, the list form of the 
macro instruction must be used. The list 
contains an address pointer and a length 
pointer; the address pointer indicates the 
location of a list containing the addresses 
at which storage is to be obtained, the 
length pointer points to a corresponding 
list of lengths specifying the size of each 
of the requested regions. In the list 
form, the address entries must contain the 
hierarchy identification in the high order 
byte if the system includes Main Storage 
Hierarchy Support. Figure 5-5 shows the 
subpool use for list and register forms of 
GETMAIN requests for region allocation; 
Figure 5-6 shows the lists and pointers. 
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Figure 5-5. Subpool Use for List and Register Forms of GETMAIN (GETPART Module) 



If a request contains a specific address 
which is not in either the dynamic area 
(between the system queue area and the link 
pack area) or within hierarchy one in sys- 
tems with Main Storage Hierarchy Support, 
the GETPART module returns with a code of 
X'08' in register 15. If the address is 
valid, but not enough storage is available, 
the requester is placed in a wait condition 
and no further requests, except for subpool 
248 (from Rollout/Rollin) , are accepted 
until the first specific address request is 
satisfied. 

In a Model 65 Multiprocessing Systan, if 
the requested storage area is not avail- 
able, GETPART determines from FSSEMAP 
whether any of the storage has been logi- 
cally removed from the system. (See Sec- 
tion 12 "control Blocks and Tables" for a 
description of FSSEMAP.) A storage area 
may be marked offline in FSSEMAP if (1) a 
VARY STORAGE OFFLINE command has been 
issued, (2) the storage address range is 
set disabled (determined by the Multi- 



processing NIP routine) or (3) the storage 
area is malfunctioning (determined by 
Storage Reconfiguration or Multiprocessing 
NIP routines) . If any of the requested 
storage area is marked offline in FSSEMAP, 
GETPART returns with a code of x'08" in 
register 15, a message is issued that main 
storage is not available, and the job is 
abnormally terminated. If the storage is 
not marked offline, the requester is placed 
in a wait condition until the request can 
be satisfied. 

If a list request with more than one 
entry cannot be completely satisfied, all 
storage already obtained for the request is 
returned to the system. 

A FREEPART/GETPART (EXCHANGE) request 
for a specific address must be issued using 
the list form and must specify subpool 246. 
GETPART frees the region and replaces it 
with one at the address specified. In sys- 
tems with Main Storage Hierarchy Support, 
only the segment in hierarchy is freed if 





. 


■ -..u 


. 1 ?-!. 






Length 










X'80' 


Address List 




J 


' ' 


/ 






f 


Code 


Subpool 
ID 




Length 


\ 


High-order bit 
ndicates request 
For multrole 




Q 


A "1" in h 


igh-order bit indicates end of list 


hierarchies. 




Hierarchy 
ID 


Address 








Hierarchy 
ID 


Address 


^ 


, 


*- 



A "0" Address indicates 
normal GETPART for region 

A non-zero Address indicates 
specific region start address 
for GETPART 



T. 



J- 



Figure 5-6. List Structure for List Form of GETMAIN (GETPART Module) 
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a region consists of both hierarchy and 
hierarchy 1 segments (see Figure 5-5). The 
region segment described by the FREEPART/ 
GETPART request must lie wholly within the 
dynamic area. All FREEPART/GETPAST 
requests for specific addresses are assumed 
to be, within the boundaries of the original 
region; no provision is made to handle an 
invalid request. 

If the dynamic area does not contain 
sufficient free space for the requested 
region, the GETMAIN routine responds 
according to whether the GETMAIN request is 
conditional or unconditional. If the re- 
quest is conditional, the GETMAIN routine 
places a return code (4) in register 15 to 
inform the requester that space cannot be 
allocated. It then returns control to the 
requester, via the Type-1 Exit routine. 
If, however, the request is unconditional, 
the GETMAIN routine makes the requester's 
task nondispatchable , prepares for future 
reissuance of the request, and causes con- 
trol to be routed to the current routine of 
the highest priority ready task. It does 
this by : 

• Setting the TCBFCDl nondispatchability 
flag in the requester's TCB. 

• Pointing the SVC old PSW to the invok- 
ing GETMAIN macro instruction, and 
storing this restart address in the 
requester's RB old PSW. 



obtained. If hierarchy is not specified, 
allocation is made from hierarchy 0. 



Processing if the Requested Space Is 
Available 

When the initial request for a subpool 
is received, the GETMAIN routine builds a 
subpool queue element (SPQE) in the super- 
visor queue area (see Figure 5-7). The 
SPQE contains the subpool number and, if 
other subpools exist, a pointer to another 
SPQE. (Each time a request is received, 
the chain of SPQEs is scanned by the 
GETMAIN routine to determine whether the 
requested subpool exists.) 

The GETMAIN routine also builds a 
descriptor queue element (DQE) in the 
supervisor queue area, and places the 
address of the DQE into the subpool queue 
element. The DQE contains a count of the 
number of bytes of main storage allocated 
to a block in the sutopool (space within 
regions is assigned to subpools in mul- 
tiples of 2048-byte blocks). For each sub- 
secfuent request for space in the same sub- 
pool that cannot be satisfied with space 
defined by existing DQEs, the GETMAIN rou- 
tine builds another DQE. For each subse- 
quent request for space in the same subpool 
that cannot be satisfied from space 
described by existing DQEs, additional 
space is allocated (in multiples of 2048- 



Indicating to the Dispatcher that a 
task switch is needed. (It does this 
by placing zero in the "hew" TCB point- 
er lEATCBP.) 

Branching to the Type-1 Exit routine, 
which detects the task switch indica- 
tion of the "new" TCB pointer. The 
Type-1 Exit routine then branches to 
the Dispatcher to locate the highest 
priority ready task whose current rou- 
tine will be given control. 



ALLOCATING SPACE WITHIN A REGION 

Any GETMAIN macro instruction in which 
subpools 0-127, 250, 251, or 252 are speci- 
fied indicates that space within an exist- 
ing region is desired. If Main Storage 
Hierarchy Support is included in the sys- 
tem, a region may consist of segments in 
both hierarchies, or may be contained 
entirely within either hierarchy or 
hierarchy 1. If only a single-hierarchy 
region exists, all GETMAIN requests for 
tasks operating in that region will be 
directed to that hierarchy regardless of 
any hierarchy designation in the request. 
If a region consists of segments in both 
hierarchies, a GETMAIN request may specify 
the hierarchy from which storage is to be 
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Figure 5-7. Element Relationships for 
Intra-Region Allocation 
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byte blocks) to the subpool. The space is 
obtained from the free area of storage 
described by FBQEs, and a DQE is con- 
structed to describe the new block. The 
number of bytes allocated is STibtracted 
from the FBQE for the area from which 
Storage was obtained, and the FBQE is relo- 
cated if necessary. All DQEs representing 
space in the same subpool are chained 
together. After each 2048-byte block is 
assigned, it is given a storage protection 
key (see Figure 5-3) . Then, when each 
block is freed, its storage protection key 
is reset to zero. 



the following functions for subpools 0-127 
and 250-252: 

• It determines whether the newly allo- 
cated storage exceeds either the "low 
water mark" (LWM) or the "high water 
mark" (HWM) for the region. The LWM is 
the address of the highest storage 
address allocated from the bottom of 
the region, and the HWM is the address 
of the lowest storage address allocated 
from the top of the region. If either 
is exceeded, the SMF Storage routine 
stores a new value in the TCT. 



If any free space exists within the 
2048-byte blocks defined by a DQE, the 
GETMAIN routine builds a free queue element 
(FQE) within the 2 Ot 8- byte block that con- 
tains the free space, and places into it a 
count of the number of bytes available. 
All such FQEs within one contiguous area 
are chained together; the GETMAIN routine 
places the address of the first such FQE 
into the associated DQE. FQEs built in 
space assigned to subpools 0-127, 250, or 
251 are exposed to accidental damage by job 
steps, as the space is assigned the storage 
protection keys of the steps. These FQEs 
are the only supervisor queue elements so 
exposed. All others are built in areas 
that are assigned the supervisor storage 
protection key. 

To locate free space in an existing sub- 
pool, the GETMAIN routine first locates the 
subpool by scanning the chain of SPQEs. It 
then determines the address of the first 
DQE and scans the chain of DQEs to locate 
an FQE containing sufficient space to sat- 
isfy the request. If sufficient space 
exists, the GETMAIN routine decrements the 
count of available bytes in the FQE. If 
sufficient free space to satisfy the re- 
guest does not exist in the requested sub- 
pool, the GETMAIN routine locates space not 
yet assigned to any subpool, and adds the 
space to the requested subpool by building 
a DQE. 

If the System Management Facility (SMF) 
feature is present in the system, the 
GETMAIN routine passes control to its SMF 
Storage subroutine (GMSMFCRE). This rou- 
tine maintains storage usage information in 
the timing control table (TCT). (If Main 
Storage Hierarchy Support is included in 
the system and IBM 2361 Core Storage is 
on-line at IPL, storage information is 
maintained for both processor storage and 
2361 storage.) 

The SMF Storage routine checks the TCB 
for the address of the TCT. If there is no 
TCT, SMF storage information is not being 
recorded for this user program. If there 
is a TCT, the SMF Storage routine performs 



• It calculates the difference, in terms 
of 2048-byte blocks, between the LWM 
and HWM. A record of the minimum value 
for this difference is kept in the TCT. 
If the new allocation creates a new 
minimum, the SMF Storage routine re- 
cords the new minimum difference in the 
TCT. 

• If the rollout feature is included in 
the system and the current allocation 
is for borrowed storage, the SMF 
Storage routine records the current 
amount of borrowed storage. It also 
records the maximum amount of borrowed 
storage associated with this user at 
any one time. 

The SMF Storage routine returns control 
to the GETMAIN routine. 

After space is assigned, the GETMAIN 
routine places the address of the assigned 
space into register 1 if an SVC 10 instruc- 
tion caused entry, or places the address 
into the location specified by the pro- 
grammer if an SVC H instruction caused 
entry. 

Processing if the Requested Space Is Not 
Available 

If there is not enough free space in the 
region to satisfy the request, the GETMAIN 
routine enlarges the scope of its search 

by: 

• Purging unused modules in the region. 

• Examining a region previously borrowed 
by the requester's job step through 
rollout, if the rollout feature is part 
of the system. 

• Testing whether to schedule linkage to 
the rollout/rollin module to "borrow" 
an additional region. 

ATTEMPTING TO FREE SPACE BY PORGING UNUSED 
MODULES ; The GETMAIN routine branches to 
its CDPURGE routine to attempt to purge one 
or more unused modules in the requester's 
region. The space freed by this purge may 
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be sufficient to satisfy the carrent 
storage request. If the purge flag is set 
(hex. '80') in the TCBJPQ field of the job 
step TCB, the CDPORGE routine examines all 
contents directory entries (CDEs) in the 
job pack queue. Each CDE that has its 
"release" flag (SEL) set in its attributes 
field represents a module in the region 
that is no longer needed. That is, there 
are no outstanding requests for the module 
by any routine in the job step. For each 
such module the CDPURGE routine branches to 
the CDDESTRY routine (in CDEXIT) to dequeue 
the CDE and free the associated module and 
its extent list. After all CDEs in the 
region's job pack queue have been examined 
and all unused modules purged, the CDPURGE 
routine returns control to the main line of 
the GETMAIN routine. 

If the module purge has freed enough 
space to satisfy the request, the GETMAIN 
routine allocates the needed space to the 
requester's task. It then returns control 
to the requester, via the Type-1 Exit 
routine. 



EXAMINING A PREVIOUSLY BORROWED REGION ; If 
sufficient space cannot be freed by the 
module purge, the GETMAIN routine deter- 
mines if there is a possibility of satisfy- 
ing the storage request from space outside 
the requester's region. The requester's 
job step may previously have "borrowed" an 
additional region through the action of the 
rollout feature. If so, the borrowed 
region is searched, via a branch to the 
GMCOMHON routine. If the request is condi- 
tional and there is no borrowed region or 
the borrowed region is searched to no 
avail, the GETMAIN routine sets up a return 
code (4) and returns control to the re- 
quester, via the Type-1 Exit routine. If, 
however, the request is unconditional and 
the rollout feature is not part of the sys- 
tem, the GETMAIN routine must cause the 
abnormal termination of the requester' s 
task. It sets up a condition code (hex. 
'804')^ and branches to the ABTERM routine 
to schedule the abnormal termination. 

DETERMINING WHETHER TO SCHEDULE LINKAGE TO 
THE ROLLODT/ROLIJN MODULE ; If requested 
space in an owned or borrowed region is not 
available, the GETMAIN routine determines 
if it can schedule the rollout/rollin 
module to borrow, if possible, an addition- 
al region for use by the job step. The 
GETMAIN routine schedules linkage to the 
rollout/rollin module only if the following 
requirements are met; 

• The request is unconditional. 



^Condition Code 804 is set up for SVC 4. 
, Condition Code 80A is set up for SVC 10 . 



• The rollout feature is part of the 
system. 



• The request is made by a problem pro- 
gram or by a system routine in behalf 
of a problem program. 

• The requester's task belongs to a job 
step that is eligible to cause rollout. 
(The eligibility is indicated by the 
'set' condition of the TCBFRA flag in 
the job-step TCB. Such eligibility was 
established by a JOB or EXEC statement 
parameter (ROLL) when the job entered 
the input stream. The eligibility was 
recorded in the job- step TCB by the 
Attach routine when an initiator 
attached the job step.) 

Unless all of the above requirements are 
met, the GETMAIN routine cannot make space 
available to satisfy the storage request. 
It therefore sets up a condition code (hex. 
'804')*- to indicate that storage is 
unavailable, and branches to the ABTERM 
routine to schedule the abnormal teannina- 
tion of the requester' s task. 



SCHEDULING LINKAGE TO THE ROLLOUT/ROLLIN 
MODULE ; The GETMAIN routine schedules 
linkage to the rollout/rollin module (here- 
after called the RO/RI module) by means of 
the asynchronous exit mechanism. (This 
mechanism is described in "Scheduling a 
User Exit Routine" in Section 3, "Task 
Supervision.") Like the scheduling of other 
asynchronous exit routines, the scheduling 
of the RO/RI module involves the Stage 1 
Exit Effector, the Stage 2 Exit Effector, 
and the Stage 3 Exit Effector. Only stages 
2 and 3, however, are involved directly in 
the GETMAIN routine's attempt to schedule 
the RO/RI module. The Stage 1 Exit Effec- 
tor is used by the Nucleus Initialization 
Program during system initialization. 

If the rollout feature is to be part of 
the system, the Nucleus Initialization Pro- 
gram (NIP) uses the CIRB macro instruction 
to invoke the Stage 1 Exit Effector. Stage 
1 then gets space for and initializes a 
special permanent system IRB and a 240-byte 
work area. The IRB is called the rollout/ 
rollin IRB and is used by the supervisor to 
schedule and control the RO/RI module. The 
NIP formats the 240-byte work area into ten 
combined interruption queue elements (IQEs) 
and rollout/rollin parameter lists. Each 
IQE is used in scheduling linkage to the 
RO/RI module. Each associated parameter 
list provides input information, such as 
the requester's TCB address, needed by the 
RO/RI module. (See the IQE format in Sec- 
tion 12, "Control Blocks and Tables" for 
the format of a rollout/rollin IQE parame- 
ter list.) 
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Execution of the RO/RI module occurs 
under control of a special permanent system 
TCB of high dispatching priority. This 
ax:B, called the rollout/ rollin TCB, is 
created during the nucleus initialization 
procedure, if the rollout feature is to be 
part of the system. The position of the 
RO/RI TCB on the TCB queue, and therefore 
its dispatching priority relative to the 
other permanent system TCBs, is shovm in 
Figure 5-8. 



Rollout and rollin processing are per- 
formed as part of the rollout/rollin task 
(hereafter called the RO/RI task) . This 
task is held nondispatchable when linkage 
to the RO/RI module is not needed. The 
task is nondispatchable because its TCB 
points directly to a permanent rollout/ 
rollin PRE that is kept in a wait condi- 
tion. When linkage to the RO/RI module is 
needed, the scheduling process positions 
the IRB on the RO/RI task's RB queue. (See 
part 2 of Figure 5-9.) Since the RO/RI IRB 
is usually in a ready condition (its wait 
count equal to zero), it makes the RO/RI 
task dispatchable. 



o 



The rollouf/rollin task is nondispatchable . 







/ 


lEATCBl 


Transient Area TCB, 


CVTHEAD 


lEAHEAD 


-^ 


















IEATCB2 


Transient Area TCB2 




Communications 




Vector Table 


T 






lEATCBn 


Transient Area TCB 
n 












lEAERTCB 


System Error TCB 






t 






lEAROTCB 


Rollout/RollInTCB 










Note: The TCBs are queued 
in descending order 
of dispatching priority 


iEECVTCB 


Communications TCB 




' 


' 






IGFRMTCB 


Dynamic Device 
Reconfiguration TCB 










.. - nr>^,r,^or 




lEAM'^T'^R 


Mnster Scheduler TCB 













Roil out/Roll In TCB Roll out/Roll In PRB J Rollout/Rollin IRB 





RB Wait Count = 01 RB Walt Count = 00 




Figure 5- 8 . 



Position of Rollout/Rollin 
TCB on TCB Queue 



RB Walt Count = 00 RB Walt Count =01 



Figure 5-9. Relationship of the Rollout/ 
Rollin TCB, PRB, and IRB Dur- 
ing Scheduling of the 
Rollout/Rollin Task 



Scheduling of the RO/RI module occurs in 
two phases. Initial scheduling is done by 
the SHEDRO routine, a subroutine of the 
GETMAIN routine. Final scheduling is per- 
formed by the Stage 3 Exit Effector, after 
the GETMAIN routine has exited and the Dis- 
patcher has been entered. The Stage 3 Exit 
Effector is a subroutine of the Dispatcher. 
The stage 3 Exit Effector readies the RO/RI 
task, which is then given control by the 
Dispatcher. The processing is described in 
the next two topics. (See Figure 5-10 for 
the overall flow and Figure 5-11 for a pic- 
torial summary of the processing. ) 

Initial Scheduling of the Rollout/Rollin 
Module ; The GETMAIN routine uses its sub- 
routine, the SHEDRO routine, to perform the 
following main functions: 

• Obtains an interruption queue element 
(IQE) and rollout/rollin parameter 
list. Initializes both the IQE and the 
parameter list. 

• Places the IQE on the asynchronous exit 
queue (AEQJ) , via a branch to the Stage 
2 Exit Effector. 

• Prepares for a task switch and for 
eventual return of control to the 
requester. 

Obtaining a Rollout IQE and Parameter List ; 
The SHEDRO routine obtains an IQE and pa- 
rameter list to keep track of the rollout 
request, and to schedule and control the 
execution of the RO/RI module. It obtains 
the IQE and parameter list by means of its 
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Scheduling of Rollout: 
all Flow 



Over- 



GETIQE routine (invoked at location 
IQERODT) . The GETIQE routine obtains them, 
if possible, from a "next available" list 
(RBNEXAV) queued from the RO/RI IRB. If 
there are no more available IQEs, the 
GETIQE routine obtains the needed space (24 
bytes, subpool 255), via a branch to the 
GETMAIN routine. If it obtains space, the 
routine initializes the IQE and parameter 
list. After the GETIQE routine has 
obtained the IQE and parameter list, it 
returns control to the SHEDRO routine. The 
SHEDRO routine then initializes the IQE to 
indicate a rollout request, and places in 
the parameter list the address of the 
requester's TCB and the size of the 
requested space. 

Placing the IQE on the Asynchronous Exit 
Queue ; The SHEDRO routine uses its SCHE- 
DIRB subroutine to invoke the Stage 2 Exit 
Effector. The Stage 2 Exit Effector then 
places the IQE representing the rollout re- 
quest onto the asynchronous exit queue. 
(See Figure 5-11.) This is the same queue 
on which the Stage 2 Exit Effector places 
IQEs that represent requests for an end-of- 
task exit routine (ETXR) or a timer exit 
routine. The Stage 3 Exit Effector, when 



the Dispatcher is next entered, completes 
the scheduling of the exit routines whose 
IRBs are represented on the queue. 
Although the IQEs are placed on the asyn- 
chronous exit queue in first-in, first-out 
order, the represented requests are ser- 
viced by the Stage 3 Exit Effector on a 
task-priority basis. 

Preparing for a Task Switch and for Eventu- 
al Return of Control to the Requester ; The 
SHEDRO routine does three things to prepare 
for a task switch and to provide for even- 
tual return of control to the requester; 

• Indicates to the Type-1 Exit routine 
that a task switch is needed. 

• Makes the requester's task nondispatch- 
able (sets the TCBWFC flag) . 

• Points the SVC old PSW to a restart 
address in the requester's task. 

The SHEDRO routine indicates the need 
for a task switch by storing zero in the 
"new" TCB pointer (lEATCBP) . Without such 
an indication, the Type-1 Exit routine, 
when entered during the exiting procedure 
from GETMAIN, would return control to the 
routine that had issued the GETMAIN macro 
instruction. With the task switch indica- 
tion, the Type-1 Exit routine branches to 
the Dispatcher, which then determine the 
task to which it will give control. 

The SHEDRO routine makes the requester's 
task nondispatchable to prevent accidental 
redispatching of the requester's task 
before its needed storage space has been 
allocated. 

The SHEDRO routine points the SVC old 
PSW to the GETMAIN macro instruction issued 
by the requester. (This procedure is 
described in the program listing as "back- 
ing up the PSW," since it causes the 
restart address to be two bytes earlier in 
the requesting routine than the normal 
address in the SVC old PSW.) The old PSW 
is altered so that when rollout is success- 
ful, the requester can be redispatched to 
reissue its GETMAIN macro instruction. The 
GETMAIN routine is then entered, via super- 
visor linkage, to satisfy the request from 
the newly borrowed region. 

Final Scheduling of the Rollout/Rollin 
Module ; During the exiting procedure from 
the GETMAIN routine, the Type-1 Exit rou- 
tine is entered, detects that a task switch 
is needed, and branches to the Dispatcher. 
The Dispatcher, finding that there is at 
least one IQE on the asynchronous exit 
queues, enters the Stage 3 Exit Effector to 
complete the scheduling of the appropriate 
asynchronous exit routine. In this case 
the appropriate exit routine is the RO/RI 
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STEP 1 



Queue origin 



STEP 2 



STEP 3 




Asynchronous Exit 
Queue for Non-I/O 
Exit- Routines (AEQJ) 

The SHEDRO routine obtains a roliout/rollin 
IQE either from an available list or by getting 
space and initializing a new IQE. The SHEDRO 
routine then Invokes the Stage 2 Exit Effector to 
place the IQE on the queue. 

Legend: 

RO/RI = roliout/rollin 
RBOPSW = RB old PSW 
^ = pointer 



IQE for roliout/rollin is removed from the asyn- 
chronous exit queue and is queued from the rollout/ 
rollin IRB by the Stage 3 Exit Effector when the 
Dispatcher is next entered. 



Rollout/Rollin 
Module 



The roliout/rollin TCB is readied by the Stage 3 
Exit Effector by placing the IRB on the task's 
RB queue. The roliout/rollin TCB now points to 
the roliout/rollin IRB, which is ready. Since 
the roliout/rollin task is now ready and of very 
high dispatching priority, the Dispatcher gives 
control to this task at location lEAQRORI in the 
roliout/rollin module. 



Figure 5-11. Steps in the Scheduling of the Rollout/Rollin Task 



module. To complete the scheduling of the 
RO/RI module, the Stage 3 Exit Effector 
performs the following main functions: 



• Removes the RO/RI IQE from the asyn- 
chronous exit queue and places it on 
the list of IQEs queued from the RO/RI 
IRB. (The IRB's list origin for IQEs 
is RBIQE.) (See Figure 5-11.) 

• Readies the RO/RI task. 

• Indicates to the Dispatcher that it 
should next dispatch the RO/RI task. 

• Moves the address of the RO/RI parame- 
ter list from the IQE to register 1 to 
serve as input information for the 
RO/RI module. 

The queuing of the IQE to the RO/RI IRB 
is recognition by the Stage 3 Exit Effector 
that the IQE represents a request for 
execution of the RO/RI module under control 
of the RO/RI TCB. The IQE remains queued 
from the IRB throughout rollout processing. 
When the RO/RI module completes its proces- 
sing of the rollout request, it dequeues 
the IQE from the IRB's active queue and 



returns it to the IRB" s "next available" 
list (RBNEXAV). 

The Stage 3 Exit Effector readies the 
RO/RI task by placing the IRB on the RO/RI 
task's RB queue, as illustrated in Figures 
5-9 and 5-11. Since the IRB is normally 
ready and the RO/RI TCB has no nondis- 
patchability flag set, the task is dis- 
patchable as soon as its RB queue is 
changed. 

The Stage 3 Exit Effector then indicates 
to the Dispatcher that it should next dis- 
patch the RO/RI task. Stage 3 does this by 
invoking the supervisor' s Task Switching 
routine and passing to it the address of 
the RO/RI TCB. The Task Switching routine 
compares the dispatching priority of the 
RO/RI TCB with that of the requester's 
task, and determines that the RO/RI task is 
ready. Since the RO/RI task is of extreme- 
ly high dispatching priority and is ready, 
the Task Switching routine selects the 
RO/RI TCB and places its address in the 
"new" TCB pointer as information for the 
Dispatcher. The invoking of the Task 
Switching routine is necessary, since 
otherwise the Dispatcher would remain 
unaware that a task is ready that is higher 
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in priority than the current task. The 
Dispatcher can never discover a higher 
priority ready task by searching the TCB 
queue. When it searches the TCB queue, it 
searches in a downward-priority direction, 
beginning with the current TCB. 

The address of the BO/RI parameter list, 
when moved from the IQE to register 1, 
serves an important purpose. It indicates 
to the RO/RI module the type of service 
that it should perform. If the address is 
positive, the request is for rollout. If, 
however, the address is negative, the re- 
quest is for rollin. Lastly, if the 
address is zero, the request is to resched- 
ule rollout processing for deferred rollout 
requests. These requests had earlier 
caused entry to the RO/RI module, but a job 
step suitable to be rolled out could not be 
found. (The handling of deferred rollout 
requests will be described later in "Pro- 
cessing If a Job Step Suitable for Rollout 
Cannot Be Found" and "Performing Final Com- 
mon Processing.") 



• Processing if a suitable job step and 
region cannot be found. 

• Processing if a suitable job step can 
be found. This processing includes 
allocating the selected region if its 
contents are already rolled out but the 
region is not in use. If the contents 
of the region are not already rolled 
out, the processing includes setting 
nondispatchable the tasks of the job 
step to be rolled out, deferring its 
I/O requests, and deferring its opera- 
tor replies. 

• Transferring the contents of the 
selected region to the rollout data 
set. 

• Allocating the borrowed region to the 
requester's job step. 

• Processing if there was an unrecover- 
able I/O error during the rollout. 

• Preparing for exit from the rollout/ 
rollin module. 



ALLOCATING A BORROWED REGION THROUGH 
ROLLOUT 



Determining whether Rollout Should Be 
Performed 



Rollout is an attempt to allocate tem- 
porarily an extra region for a job step 
that needs more space than is available in 
its existing region or regions. The RO/RI 
module first tries to allocate the extra 
region from free space in the dynamic area. 
If, however, there is not enough contiguous 
free space, the RO/RI module writes the 
contents of another job-step's region from 
main storage to auxiliary storage. The 
"borrowed" region is then allocated to the 
requester's job step. 

The RO/RI module consists of a central 
routine, called the Rollout/Rollin Criteri- 
on routine, and various subroutines. The 
RO/RI Criterion routine coordinates the 
rollout activities of the subroutines. 
These activities include deferring I/O 
requests for the job step to be rolled out, 
deferring its operator replies, setting its 
tasks nondispatchable, and causing the 
transfer of the contents of the selected 
region to the rollout data set. 

The main functions performed during 
rollout are: 

• Determining whether rollout should be 
performed . 

• Obtaining the needed space from unas- 
signed storage. 

• Finding a job step and region suitable 
to be rolled out. 



The RO/RI Criterion routine, when dis- 
patched at entry point lEAQRORI, determines 
first whether rollout is being requested, 
then whether rollout should be performed. 
If rollout should not be performed, the 
RO/RI Criterion routine defers the current 
rollout request and branches to the 
Rollout/Rollin Exit subroutine to prepare 
for exit from the RO/RI module. If rollout 
should be performed, the RO/RI Criterion 
routine continues processing. In determin- 
ing whether rollout should be performed, 
the routine does the following: 

• Determines whether the current request 
is for rollout, rollin, or restart of 
deferred rollout requests. Routes con- 
trol to the appropriate part of the 
RO/RI Criterion routine to service the 
request. 

• Determines whether another job step has 
caused a rollout that is still in 
effect. 

• Defers the current rollout request, if 
"multiple rollouts" are prohibited and 
if another job step has caused a roll- 
out that is still in effect. 

• Continues processing the ciirrent roll- 
out request if no other job step has 
caused a rollout that is still in 
effect, or if another rollout is still 
in effect but a user-written appendage 
permits multiple rollouts. 
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DETERMINING WHETHER THE CURRENT REQUEST IS 
FOR ROLLOUT ; The RO/RI Criterion routine 
determines the type of request by testing 
the parameter list address passed to the 
RO/RI module in register 1. If the address 
is positive, the request is for rollout. 
(The polarity of the parameter list address 
in the RO/RI IQE was set by the GETMAIN 
routine's SHEDRO or SCHEDRRI routine when 
it scheduled linkage to the RO/RI module- 
The parameter list address was placed in 
register 1 by the Stage 3 Exit Effector 
during the final phase of scheduling. ) 



DETERMINING WHETHER ANOTHER JOB STEP HAS 
CAUSED A ROLLOUT THAT IS STILL IN EFFECT ; 
The RO/RI Criterion routine tests the 
"rollouts invoked" counter and, if neces- 
sary, examines the TCB queue to determine 
if a job step other than the requester" s 
has caused a rollout that is still in 
effect. These tests are made because con- 
current rollouts for different requesting 
job steps are not allowed, unless permitted 
by the choice of a user-written Coincident 
Rollout appendage (lEAQAPGl) . Such "mul- 
tiple rollouts" are not normally permitted 
because concurrent requesting job steps 
could each attempt to roll out more than 
half of the main storage space available 
for rollout. In that case, the competing 
job steps would be placed on the deferred 
request queue, awaiting main storage space 
that would never be available. The system 
would thus be in an "interlock," unable to 
continue processing. 



DEFERRING THE CURRENT ROLLOUT REQUEST ; The 
RO/RI Criterion routine defers the current 
rollout request, if multiple rollouts are 
prohibited, and if another job step has 
caused a rollout that is still in effect. 
The routine defers the rollout request by 
transferring the requester's IQE from the 
RO/RI IRB's queue of active IQEs to wait 
queue called the "rollout request queue. " 
(The origin of the rollout request queue is 
defined in the secondary communications 
vector table as lEAROQUE.) The IQEs on the 
rollout queue are rescheduled for new link- 
age to the RO/RI module after either of two 
events has occurred: a region's contents 
have been rolled in, or the DEQ routine has 
marked a job- step TCB as eligible to be 
rolled out (TCBNROC equals zero) . Either 
event means that another region is avail- 
able for possible rollout. (For further 
information on the restart of deferred 
rollout requests, see "Performing Final 
Common Processing.") 

DETERMINING IF PROCESSING OF THE CURRENT 
ROLLOUT REQUEST SHOULD BE CONTINUED ; The 
RO/RI Criterion routine continues process- 
ing the current rollout request if no other 
job step has caused a rollout that is still 



in effect, or if another competing rollout 
is still in effect but a user- written 
appendage permits such multiple rollouts. 
Without a user appendage, the RO/RI Crite- 
rion routine continues the processing of 
the current request only if no other job 
step has caused a rollout that is still in 
effect. A user-written appendage, if pro- 
vided, can be substituted for the IBM- 
provided decision. Decisions made in the 
user appendage can provide flexible control 
of the number of job steps that can concur- 
rently invoke rollout. 

Mote : If the user appendage allows more 
than one job step to invoke rollout concur- 
rently, it is responsible for preventing 
interlocks. 



Obtaining the Needed Space from Unassigned 
Storage 

If the RO/RI Criterion routine decides 
that rollout should be performed, it tries 
to obtain a new region from unallocated 
space in the dynamic area via a conditional 
GETMAIN macro instruction that specifies 
subpool 2U8. The result is supervisor 
linkage to the GETMAIN routine. If there 
is insufficient space, the GETMAIN routine 
returns a code of '4', and the RO/RI Crite- 
rion routine then tries to find a job step 
and region suitable to be rolled out. If, 
however, the GETMAIN routine can allocate a 
new region, it builds a partition queue 
element (PQE) and a free block queue ele- 
ment (FBQE) , and queues the PQE from the 
RO/RI TCB. The GETMAIN routine in this 
case supplies the RO/RI Criterion routine 
with a code of '0', indicating that the 
region has been allocated, and provides the 
address of the PQE representing the new 
region. (The PQE address is returned in a 
parameter list.) 

When the RO/RI Criterion routine detects 
that a new region has been allocated, it 
does the following; 

• Removes the newly created PQE from the 
RO/RI task's PQE queue and places it on 
the PQE queue of the requester's job 
step TCB. The routine reorders the PQE 
queue, if necessary, so that the PQEs 
are queued according to ascending order 
of region addresses. 

• Initializes the TCB address (PQETCB) in 
the new PQE to zero to indicate that 
the region was allocated from free 
space. This field is tested during 
rollin to determine whether the region 
should be freed. 

• Increases the "rollouts invoked" count- 
er (lEAROICT) by a count of 'one', to 
indicate that a rollout has been 
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invoked and is still in effect. This 
counter is tested each time that the 
RO/RI Criterion routine is entered for 
rollout, to determine whether rollout 
should be performed. (See "Determining 
Whether Rollout Should Be Perfoinned.") 

• Sets the "borrowed" flag (PQEBOR) in 
the rollout flags field of the new PQE. 
This flag, when set, indicates that the 
region described by the PQE is not 
"owned" by the job step to which it is 
allocated. 

• Sets the "rollout invoked" flag 
(TCBFRI) in the requester's job-step 
TCB. This flag, when set, indicates 
that the job step has invoked one or 
more rollouts that are still in effect. 

• Makes the requester's task dispatchable 
by clearing the "core wait" nondis- 
patchability flag (TCBWFC) . This is 
done in preparation for the redispatch- 
ing of the requester's task. 

• Branches to the RO/RI module's Retexit 
routine to prepare for exiting from the 
RO/RI module. (See "Preparation for 
Exit from the Rollout/Rollin Module.") 



Obtaining a Job Step Suitable to be Rolled 
Out 

If a new region cannot be allocated from 
free space, the RO/RI Criterion routine 
tries to obtain a job step that is suitable 
to be rolled out. A job step is suitable 
if: 

• It has not caused a rollout which is 
still in effect. 

• Its TCB is marked eligible to be rolled 
out. 

• It owns a region that is large enough 
to satisfy the current storage request 
and that is not already in use by a 
borrower . 

The process of obtaining a job step 
suitable to be rolled out consists of two 
functional parts: finding a job step, and 
testing the selected job step to see that 
is meets the above requirements. 



FINDING A JOB STEP: 



The RO/RI Criterion 



routine branches to the GETSTEP routine to 
find a job step whose suitability can be 
tested. The GETSTEP routine receives as 
input parameters the address of the reques- 
ter's job step TCB and the address of the 
rollout parameter list. The parameter list 
contains the size of the requested storage. 



The GETSTEP routine performs the following 
functions : 

• Deteinnines if the requester's job step 
has previously caused a rollout that is 
still in effect. (The routine tests 
the TCBFRI flag in the requester's job 
step TCB.) A requesting job step may 
invoke successive rollouts which are 
concurrently in effect. 

• If so, invokes the TESTSTEP routine to 
test if one or more regions previously 
borrowed by the requester's job step 
contain enough free space to satisfy 
the current request. 

• Searches the TCB queue for a lower 
priority job step which may be tested 
for suitability, if the current request 
cannot be satisfied from a previously 
borrowed region. The TCB queue is 
searched in a downward priority direc- 
tion, starting with the requester's job 
step TCB and ending with the last TCB 
on the queue. The routine saves the 
address of the lowest priority job step 
TCB that it finds. 

• Branches to the TESTSTEP routine to 
test the suitability of the selected 
job step. If the job step is not suit- 
able, the GETSTEP routine repeats its 
search of the TCB queue. This time, 
however, the search ends with the pre- 
viously selected TCB. The search is 
finished when a suitable job step has 
been found, or when all job steps lower 
in priority than the requester' s have 
been examined and none has proved 
suitable. 

• Branches to an optional user-written 
appendage (IEAQAPG2), if it cannot find 
a job step which is suitable to be 
rolled out. The user (High Priority 
Pass) appendage, if present, dynamical- 
ly determines whether the GETSTEP rou- 
tine should make a new search of the 
TCB queue, this time examining job 
steps that are higher in priority than 
the requester's. 

• Searches the TCB queue for a higher 
priority job step which may be tested 
for suitability, if the High Priority 
Pass appendage so decides. The TCB 
queue is searched in a downward priori- 
ty direction, starting with the master 
scheduler TCB and ending with the 
requester's job step TCB. The search 
and examination of job steps is similar 
to the low priority search previously 
described. 

• Returns control to either of two return 
points in the RO/RI Criterion routine, 
after completing its examination of job 



Section 5: Main Storage Supervision 119 



steps that were candidates for rollout. 
The particular return point depends on 
whether a job step suitable for rollout 
has been found. If the GETSTEP routine 
finds a suitable job step, it places in 
register the address of the PQE 
belonging to the job step. 

TESTING THE SELECTED JOB STEP ; Each job 
step selected by the GETSTEP routine is 
further tested for suitability by the TEST- 
STEP routine. The TESTSTEP routine deter- 
mines that a selected job step is suitable 
to be rolled out if: 

• The job step has not invoked a rollout 
which is still in effect. (Although 
concurrent rollouts may be permitted by 
a user appendage (lEAQAPGl) , nested 
rollouts are never permitted. A nested 
rollout is the rollout of a job step 
that has itself caused a rollout that 
is still in effect.) 

• The job step is eligible to be rolled 
out. The step is eligible if the "non- 
rolloutable count" (TCBNROC) is zero in 
its TCB. A zero count means that the 
job step was initialized as eligible 
when it was attached and is not cur- 
rently using or waiting to use a system 
resource that requires the ENQ macro 
instruction. The nonrolloutable count 
was initialized to either zero or one 
by the Attach routine when an initiator 
attached the job step. The initializa- 
tion reflects the job step's eligibili- 
ty to be rolled out, as specified by 
the ROLL operand of the JOB or EXEC 
statement when the job was placed in 
the input stream. The nonrolloutable 
count, after initialization, is 
increased by one by the ENQ routine for 
each system resource for which an ENQ 
macro instruction is issued by the job 
step. The count is similarly decreased 
by the DEQ routine for each issuance of 
the DEQ macro instruction by the job 
step. 

• The job-step's region is large enough 
to satisfy the current storage request. 



• The region is not being used by a job 
step that has invoked rollout. Such a 
borrower could be either the current 
requester's job step, if it has pre- 
viously invoked rollout, or another 
requesting job step if concurrent roll- 
outs are permitted. If the region is 
not being used by a borrower, its "in 
use" flag (PQEUSE) in the PQERFLGS 
field is zero. 



• The job step and its region are 

approved by a user-written appendage. 



if such an appendage has been provided. 
The Criterion Selection appendage 
(lEAQAPGt) can be provided by the 
installation to make further tests of a 
job step already approved by the TESTS- 
TEP routine. 

• Returns control to the caller (usually 
the GETSTEP routine) , with the PQE 
address in register if it has 
approved the job step and region. 

Processing if a Job Step Suitable for 
Rollout Cannot be Found 

If the GETSTEP routine cannot find a job 
step suitable to be rolled out, the RO/RI 
Criterion routine can follow either of two 
possible courses of action. If can cause 
the abnormal termination of a job step, or 
it can defer the current rollout request by 
placing the requester's IQE on a wait queue 
called the "rollout queue." The particular 
choice depends on the decision of a user- 
written ABEND appendage (IEAQAPG3) , if the 
appendage is present. If the appendage is 
not present, the current rollout request is 
deferred. 

CAUSING THE ABNORMAL TERMINATION OF A JOB 
STEP ; The ABEND appendage, if present, can 
request the abnormal termination of either 
the requester's job step or another job 
step in the system. The appendage provides 
the address of the selected job step TCB in 
a register. Termination of the requester's 
job step removes it from the system if it 
cannot wait for storage to become avail- 
able. Termination of another job step 
results in the freeing of a region. After 
such termination is complete, the RO/RI 
module is reentered twice; first to per- 
form rollin, then to make a new attempt at 
rollout for the deferred request. (See 
"Scheduling Deferred Rollout Requests.") 

If the requester's job-step task is to 
be terminated, the RO/RI Criterion routine 
branches to the ABTERM routine, providing 
the address of the requester's job step 
TCB. The ABTERM routine schedules the 
abnormal termination of the job step, then 
returns control to the RO/RI Criterion rou- 
tine. The RO/RI Criterion routine sets the 
requester's task dispatchable (clears the 
TCBWFC flag) , and branches to the RETEXIT 
routine. The RETEXIT routine prepares for 
exiting from the RO/RI module and eventual 
dispatching of a task of an another job 
step. (See "Exiting from the Rollout/ 
Rollin Module.") 

If a job step other then the requester's 
is to be terminated, the RO/RI Criterion 
routine first determines that the TCB spec- 
ified by the ABEND appendage is really a 
job step TCB. If the TCB is really a job 
step TCB, the routine branches to the 
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ABTERM routine to schedule the abnormal 
termination of the specified job step. It 
then defers the current rollout request, by 
placing the requester's IQE on the rollout 
queue. If, however, the TCB specified for 
abnormal termination is not really a job 
step TCB, the RO/RI Criterion routine 
defers the current rollout request without 
scheduling an abnormal termination. 



DEFERRING THE CURRENT ROLLOOT REQUEST ; The 
RO/RI Criterion routine defers the current 
rollout request if the ABEND appendage 
(IEAQAPG3) decides against a termination 
(or if there is no ABEND appendage) . The 
rollout request is deferred until space is 
freed or until an ineligible job step is 
made eligible to be rolled out. (The 
method of deferring a rollout request is 
described in "Determining Whether Rollout 
Should Be Performed . " The restart of 
deferred rollout requests is described in 
"Performing Final Common Processing.") 
After deferring the current rollout re- 
quest, the RO/RI Criterion routine branches 
to the Rollout Exit routine to prepare for 
a task switch and for return of control to 
another task. (See "Exiting from the 
Rollout/Rollin Module.") 



Processing if a Suitable Job Step 
Can be Found 

If the GETSTEP routine finds a suitable 
job step to be rolled out, it returns con- 
trol to the main line of the RO/RI Criter- 
ion routine, providing the address of the 
selected PQE. This PQE describes the 
region that is allocated to the requester's 
job step. The region's contents can be in 
either of two conditions: already rolled 
out for a requester but not in use, or not 
already rolled out. 



If the contents of the selected region 
have already been rolled out, the RO/RI 
routine does not attempt a second rollout. 
In this case, the routine merely allocates 
the selected region to the requester' s job 
step. 

If, however, the contents of the 
selected region have not already been 
rolled out, the RO/RI Criterion routine 
prepares to roll out the region's contents 
to the rollout data set. (See "Preparing 
to Roll Out the Contents of the Selected 
Region.") 

If Main Storage Hierarchy Support is 
included in the system, and a task whose 
region is selected for rollout has another 
region in either hierarchy or 1, this 
remaining region is not affected by 
rollout. 



ALLOCATING THE SELECTED REGION ; The 
selected region is allocated to the reques- 
ter's job step if two conditions are met: 
the region's contents have already been 
rolled out, and the region is not being 
used. The RO/RI Criterion routine tests 
only whether the region' s contents have 
been rolled out. The TESTSTEP routine pre- 
viously tested whether the region is in 
use. 

If the conditions are met, the RO/RI 
Criterion routine allocates the selected 
region to the requester's job step by per- 
forming the following functions; 



• Sets the "rollout" flag (PQERO) and the 
"in use" flag (PQEUSE) in the owner's 
PQE to indicate that the contents of 
the region have been rolled out and 
that the region is being used by a bor- 
rowing job step. 

• Branches to the BUILDPQE subroutine to 
obtain space for and initialize a new 
PQE to describe the borrowed region. 
The RO/RI Criterion routine will later 
place this PQE on the PQE queue of the 
requester's job step. The new PQE is 
initialized to point to a free block 
queue element (FBQE) that describes as 
free the entire borrowed region. The 
last four words of the new PQE are 
copied from the corresponding fields of 
the owner's PQE. (These fields contain 
the owning job step's TCB address, the 
region size, the region address, and 
flags. See Section 12, "Control Blocks 
and Tables," for additional format 
information. ) There are thus two PQEs 
describing the same region: the 
owner's PQE and the borrower's PQE, 
associated with different job step 
TCBs. The owner's PQE is flagged 
"owned," "rolled out," and "in use." 
The borrower's PQE is flagged 
"borrowed. " 

• Branches to the SETKEYS subroutine to 
set to zero the storage key of all 2K 
blocks in the region. This is done so 
that no user routine can store informa- 
tion in the region before the GETMAIN 
routine has been reentered to allocate 
the region's space to the current 
requester. 

• Branches to location RR004 to: 
increase the "rollouts invoked" count- 
er, set the "borrowed" flag^ (PQEBOR) 
in the new PQE, place the new PQE on 



^The "borrowed" flag is set in the new PQE 
to indicate that the represented region is 
not owned by the job step to which it is 
allocated. 
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the PQE queue of the requester's job 
step, set the "rollout invoked" flag 
(TCBFRI) in the requester's job step 
TCB, and clear the "core wait" nondis- 
patchability flag (TCBWFC) in the 
requester's TCB. (See "Obtaining the 
Needed Space from Unassigned Storage" 
for a discussion of these actions.) 

• Branches to the RETEXIT routine to pre- 
pare for exit from the RO/RI module and 
return control to the requester's task. 
(See "Exiting from the Rollout/Rollin 
Module.") 

PREPARING TO ROLLOUT THE CONTENTS OF THE 
SELECTED REGION ; The RO/RI Criterion rou- 
tine prepares to roll out the contents of 
the selected region, if they have not al- 
ready been rolled out. Preparation con- 
sists of the following functions, performed 
for the job step to be rolled out: 

• Setting nondispatchable the tasks of 
the job step. This is done to prevent 
the restart of these tasks by the Dis- 
patcher while the job step is not in 
main storage. 

• Deferring the job- step's I/O requests. 
I/O commands that are executed for the 
job step after it has been rolled out 
could cause information to be read into 
or written from main storage areas that 
no longer belong to the job step. To 
prevent this, queued I/O request ele- 
ments, which represent channel programs 
not yet executed, are purged. Pointers 
to I/O blocks (lOBs) associated with 
these request elements however, are 
saved to permit restart. The purged 
request elements are reinstated when 
the rolled out job step has been rolled 
in- Active I/O requests however, which 
represent channel programs being cur- 
rently executed, are allowed to com- 
plete before the job step is rolled 
out. (Figure 5-12 illustrates the 
overall functional flow) . 

• Deferring the job-step's operator 
replies. Replies received while the 
job step is rolled out must not be read 
into main storage areas that no longer 
belong to the job step for which they 
were issued. These replies are there- 
fore saved in temporary buffers, and 
are later transferred to the appropri- 
ate user buffers when the rolled out 
step has been rolled in. 

Setting Nondispatchable the Tasks of the 
Job Step ; The RO/RI Criterion routine 
issues the STATUS macro instruction to 
cause supervisor linkage to the Set Status 
routine (IGC079). This routine sets non- 
dispatchable all tasks of the specified job 
step by setting the TCBFRO flag in each TCB. 



Refurn 

to 

Caller 




SVC Purge Rout'irie 



PURGE macro instruction 
(S) 



Removes queued I/O requests. 
Determines that there are active 
requests for I/O that have not 
quiesced. 



WAIT macro issuei 



Wait Routine 



Wait for posting of purge ECB 
by Purge Completion Subroutine. 



(S) 



Type - 1 Exit Routine 



Dispatcher 



Operation of other lower priority tasks. 



SVC Purge Routine 



Complete purge of RQEs. 



I/O IntSupvsr 



I/O Complete 



Purge Completion Subr 



Check count of incomplete 
I/O requests to be quiesced. 




Figure 5-12. Interfaces Between Rollout 

Module and SVC Purge Routine 
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The operands of the STATUS macro 
instruction, as used above, have these 
meanings : 



STATUS |SET ND, | (1) 

[causes 
setting of 
nondis- 
patchabil- 
ity flag 
specified 
by mask 
operand 
(12). 



(12) 



j Indicates j 
I that the | 
|TCB whose I 
I address is | 
jin register] 
|1 and its | 
I descendants \ 
(should be j 
I set as I 
[specified. | 



This mask 
number indi- 
cates that 
the "rolled 
out" nondis- 
patchability 
flag (TCBFRO) 
should be 
set. 



Deferring the Job-Step's I/O Requests ; The 
RO/RI Criterion routine branches to the SVC 
Purge Interface routine (PRGIO) to defer 
the job-step's I/O requests. The SVC Purge 
Interface routine performs the following 
functions for each task of the job step: 

• Obtains space for and initializes a 
rollout I/O queue element (RIQE)^. 
Each RIQE serves as a list origin for a 
queue of I/O blocks (lOBs) that repre- 
sent the task's deferred channel pro- 
grams. The lOBs are used to restart 
the channel programs after the job step 
has been rolled in. 

• Stores in the SVC purge parameter list^ 
the address of the TCB whose queued re- 
quest elements are to be purged. Also 
places in the purge parameter list a 
pointer to the lOB list origin in the 
RIQE. The I/O Supervisor's SVC Purge 
routine uses this parameter list during 
its purge of the task's request 
elements . 

• Issues a PURGE macro instruction to 
gain supervisor linkage to the I/O 
Supervisor's SVC Purge routine 
(IGC016). Flags (X'02') in the purge 
parameter list specify the "purge by 
TCB" and "quiesce" options. The 
address of the purge parameter list is 
provided in register 1. (See the pub- 
lication I/O Supervisor PLM for 
detailed information on the SVC Purge 
routine. ) 

The SVC Purge routine searches the sys- 
tem queues for I/O request elements 
belonging to the specified task. It 
removes from the logical channel queues 
and the seek queues the request ele- 
ments that are not yet active. It 
returns these request elements to the 
free list in the lOS . It queues their 
associated lOBs from the list origin in 



^See Section 12, "Control Blocks and 
Tables." 



the input RIQE, so that the lOBs would 
be available when I/O operations are 
resumed. (See Figure 5-13.) 

The routine then waits for completion 
of active I/O requests. Such requests 
represent I/O operations in process. 
The routine waits by issuing a wait 
macro instruction specifying the purge 
ECB and a wait count equal to the numb- 
er of I/O requests that must complete. 
(The address of the purge ECB is in the 
SVC purge parameter list.) 

During the subsequent wait period, con- 
trol is given to lower priority tasks 
in the system. When each active I/O 
request completes, the I/O Interruption 
Supervisor received control and 
branches to the Purge Completion sub- 
routine. This subroutine, part of the 
SVC Purge routine, decreases and tests 
the count of I/O requests awaiting com- 
pletion. (This count is kept at offset 
8 in the SVC purge parameter list.) 
When the count reaches zero, the Purge 
Completion subroutine posts the purge 
ECB complete, and the Dispatcher 
returns control to the main line of the 
SVC Purge routine. The SVC Purge rou- 
tine then completes the purge of queued 
request elements, and returns control 
to the RO/RI module's SVC Purge Inter- 
face routine. 

Returns control to the RO/RI Criterion 
routine to continue the preparation for 
rollout, after the SVC Purge routine 
has been invoked for all tasks of the 
job step. 



Deferring the Job-Step's Operator Replies ; 
The RO/RI Criterion routine branches to the 
Reply Purge routine (PRGRQE) . This routine 
sets the "rollout" flag in reply queue ele- 
ments belonging to the job step to be 
rolled out. The reply queue elements 
represent operator replies not yet received 
by the job step. If a reply is received 
while the job step is rolled out, the com- 
munications task Reply Processor routine 
(IGC1203D) determines that the rollout flag 
is set in the reply queue element, and 
saves the reply in a temporary buffer until 
the job step is rolled in. (See "Reply 
Processing" in Section 7, "Console Communi- 
cations and System Log.") 

To flag outstanding replies, the Reply 
Purge routine: 

• Finds each reply queue element belong- 
ing to the job step being rolled out. 
It recognizes the element by its TCB 
pointer (RQETCB) and the job- step TCB 
pointer in the specified TCB. (See 
Section 12, "Control Blocks and 
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Parameter List for SVC Purge Routrne 



Points to lOBRESTR Field 
of Last-Queued lOB 



Legend: 

RIQE = Rollout I/O Queue Element 
numerals - offset in bytes 
*■ = pointer 



Figure 5-13. How lOBs for Deferred I/O Requests are Queued 



Tables," for the format of a reply 
queue element.) 

Ignores reply queue elements belonging 
to other rolled out steps (meaningful 
only if concurrent rollouts are per- 
mitted) . Also ignores reply queue ele- 
ments flagged for purge. These latter 
elements were flagged by the WTOR Purge 
routine (lEECVPRG) because of a normal 
or abnormal task termination and are 
purged by the Reply Processor routine 
(IGC1203D). 

Sets the rollout flag (RQERO) in the 
selected reply queue element as an 



indication for the Reply Processor 
routine. 

• Returns control to the RO/RI Criterion 
routine when all reply queue elements 
on the queue have been examined, and 
elements belonging to the job step have 
been flagged. 

Transferring the Contents of the Selected 
Region to the Rollout Data Set 

When preparation for rollout is com- 
plete, the RO/RI Criterion routine branches 
to the Start Transfer routine (STARTIO) , 
passing the address of the PQE for the 



124 



selected region. This routine starts and 
controls the transfer of the selected 
region's contents to the rollout data set. 
It is also used during rollin to transfer 
the rolled out job step from the rollout 
data set to its region of main storage. 

The Start Transfer routine does the 
following : 

• Initializes the channel programs. 

• Starts the channel programs. 

• Reinitializes the channel programs. 

• Handles a normal channel-end condition. 

• Handles an end-of-cylinder condition. 

• Responds to the type of completion, 
normal or abnormal. 



INITIALIZING THE CHANNEL PROGRAMS; 



The 



Start Transfer routine first issues an SSM 
instruction. This instruction sets the 
system mask in the current PSW to permit 
I/O interruptions on all channels. This is 
necessary because the standard PSW under 
which the RO/RI module operates does not 
permit external and I/O interruptions. 
(The normally disabled mode of operation is 
typical of most supervisor routines.) 

The Start Transfer routine next branches 
to the Channel Program Initialization sub- 
routine (CPINIT) . This subroutine initial- 
izes two channel programs and prepares for 
the starting of the I/O device by the I/O 
Supervisor. The subroutine's functions are 
as follows: 

• Determines from the polarity of the 
input PQE address whether rollout or 
rollin is needed. 

• Calculates and saves the address of the 
region's upper boundary, for use by the 
PCI appendage routine and the Channel 
End Appendage routine in determining 
when the last record has been trans- 
ferred. (Both appendages are part of 
the Start Transfer routine.) 

• Places the data address (the starting 
address of the region) in the Read/ 
Write channel command word (CCW) of 
each channel program. 

• Sets the command code to "Write" in the 
Read/Write channel command word (CCW) 
of each channel program. (If the Start 
Transfer routine had been entered for 
rollin, the command code would be set 
to "Read".) 

• Stores in the lOBSTART field of the 
rollout input/output block (lOB) the 



address of the Search ID Equal command 
of the first channel program. (The I/O 
Supervisor uses this address in a 
Transfer in Channel (TIC) to the Search 
command to start the channel program.) 

• Sets the NOP command code in the NOP/ 
TIC command in both channel programs. 
(The PCI Appendage routine will later 
change one of these commands to a TIC.) 

• Calculates the relative disk address 
(TTR) at which writing (or reading) 
will begin in the rollout data set. 
This address, when converted to an 
absolute address, will be used in the 
Seek command to be issued by the I/O 
Supervisor. The following formula is 
used to calculate the relative disk 
address: 

TTR = ((R - Ki)/Ri)/N 

where: 

R = the address of the region whose 

contents are to be rolled out (or 
rolled in) . 

Ki = the address of the last byte of 
the system queue area plus one. 
(This address was stored in the 
GOVRFLB table by the Nucleus 
Initialization Program (NIP) . 

Rj. = record size in bytes. 

N = number of records per track on the 
direct access device. 

• Branches to a convert routine 
(lECPCNVT) whose address is in the com- 
munications vector table. This routine 
converts the relative disk address 
(TTR) to an absolute disk address 
(MBBCCHHR) . 

• Places the absolute disk address in the 
lOBSEEK field of the rollout lOB for 
use by the I/O Supervisor in its Seek 
command . 

STARTING THE CHANNEL PROGRAMS : The Start 
Transfer routine starts execution of the 
channel programs by issuing an EXCP macro 
instruction which specifies the rollout 
lOB. The EXCP macro instruction causes 
supervisor linkage to the EXCP Supervisor, 
which starts the first channel program. 

After the first channel program has been 
started, the I/O Supervisor returns control 
to the Start Transfer routine, via the I/O 
First-Level Interruption Handler and the 
Dispatcher. The Start Transfer routine 
then issues a WAIT macro instruction, spec- 
ifying the rollout event control block 
(ECB) . The macro instruction causes super- 
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visor linkage to the Wait routine, which 
places the Start Transfer routine and the 
RO/RI IRB in a wait condition. They await 
the posting of the rollout ECB by the I/O 
Supervisor. The posting will indicate 
either that the channel programs have com- 
pleted the data transfer or that an I/O 
error has occurred. Until the rollout ECB 
is posted, control is given to other lower 
priority tasks, via the Dispatcher. 



REINITIALIZING THE CHANNEL PROGRAMS ; When 
the channel fetches the Read/Write command, 
it detects that the program- controlled 
interruption (PCI) flag is set in the com- 
mand. (The PCI flag is bit 36 in the 64- 
bit CCW.) The channel then interrupts the 
CPU, although continuing the execution of 
the channel command. The PCI Interruption 
causes supervisor linkage to the I/O Super- 
visor. The I/O Supervisor determines the 
cause of the interruption and branches to 
the RO/RI module's PCI Appendage routine 
(PCIAPG). 



The PCI Appendage routine determines 
whether the last record is being trans- 
ferred. If so, the routine returns control 
immediately to the I/O Supervisor to await 
the channel-end interruption, when the last 
CCW is fetched by the channel. If, how- 
ever, the last record is not being trans- 
ferred, the routine prepares for a TIC to 
the next channel program to continue the 
transfer. The PCI Appendage routine: 

• Computes the data address for the Read/ 
Write CCW of the next channel program. 
It does this by adding the record size 
(1024) to the address field of the CCW. 

• If the sum is greater than the upper 
boundary of the region, the last record 
is being transferred. In this case, 
returns control to the I/O Supervisor- 
Control is then routed to a lower- 
priority ready task, via the I/O First- 
Level Interruption Handler and the 
Dispatcher. 

• If the sum is not greater than the 
upper boundary of the region, stores 
the computed data address in the Read/ 
Write CCW of the next channel program, 
and continues processing. 

• Places a NOP command code (hex. '03') 
in the NOP/TIC CCW of the next channel 
program. This is necessary because the 
next record could be the last record. 
In that case, the channel's detection 
of no more ccw's would cause a needed 
channel-end interruption. 

• Updates by 1024 bytes the address field 
of the Search ID Equal CCW in the next 



channel program. The search identifies 
the record to be transferred by the 
Read/Write command that follows the 
Search command. 

• Places the TIC command code (hex. 
•08') in the NOP/TIC CCW of the current 
channel program. It does this to con- 
tinue channel program execution, since 
the current record is not the last. 

• Switches the contents of the "current" 
and "next" initialization pointers, so 
that channel-program switching can 
continue. 

• Returns control to the I/O Supervisor, 
which then gives control to a lower 
priority ready task, via the I/O First- 
Level Interruption Handler and the Dis- 
patcher. Performance of the ready task 
continues, overlapping the data trans- 
fer, until it is interrupted by the 
next I/O interruption. 

HANDLING A CHANNEL-END CONDITION ; A 
channel-end interruption occurs after the 
channel executes a NOP/TIC command that has 
not been changed to a TIC by the PCI appen- 
dage. The interruption causes supervisor 
linkage to the I/O Supervisor, which deter- 
mines the cause of the interruption, and 
branches to the RO/RI module's Channel End 
Appendage . 

The Channel End Appendage deteinrines if 
the last record has been transferred. If 
so, the appendage returns control to the 
I/O Supervisor. The I/O Supervisor then 
posts the rollout ECB, indicating in the 
completion code whether the transfer has 
completed normally or with error. 

The POST macro instruction causes super- 
visor linkage to the Post routine (IGC002) , 
which places the completion code in the ECB 
and readies the waiting RO/RI IRB. The 
Post routine also alters the "new" TCB 
pointer (lEATCBP) , via the Task Switching 
routine, to indicate the need for a task 
switch. Then, the Post routine returns 
control to the RO/RI task's Start Transfer 
routine, via the Dispatcher. 

If however, the last record has not been 
transferred, the Channel End Appendage 
resets flags and an error count in the rol- 
lout lOB, and returns control to the I/O 
Supervisor to restart the channel programs. 

HANDLING AN END- OF- CYLINDER CONDITION : If 
an abnormal condition occurs at the direct 
access device, the I/O Supervisor gains 
control via supervisor linkage, determines 
the cause, and branches to the RO/RI modu- 
le's Abnormal End Appendage routine. This 
routine (ABEAPG) determines if an end-of- 
cylinder condition exists. It does this by 
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checking error indicators in the rollout 
lOB. If an end-of-cylinder condition does 
not exist, the routine returns control to 
the I/O Supervisor for further error han- 
dling. If, however, an end-of-cylinder 
condition does exist, the routine obtains 
the address of a previously executed CCW, 
stores the address in the lOBSTAST field of 
the lOB, and returns control to the I/O 
Supervisor. The I/O Supervisor then 
restarts the channel programs, beginning 
with the specified CCW. 

RESPONDING TO THE TYPE OF COMPLETION ; The 
Start Transfer routine regains control from 
the Dispatcher when the I/O Supervisor has 
posted the rollout ECB. Control is 
returned to the instruction immediately 
following the WAIT macro instruction. The 
ECB is posted when any of the following 
conditions has occurred: 

• The region's contents have been trans- 
ferred without error. 

• An error has occurred after a channel- 
end interruption. This type of error 
may be recoverable. 

• An unrecoverable error has occurred. 

The Start Transfer routine determines 
the type of completion by examining the 
completion code in the rollout ECB. (See 
Section 12, "Control Blocks and Tables," 
for the ECB completion codes . ) 

If the region's contents have been 
transferred without error, the routine 
returns control to the RO/RI Criterion rou- 
tine. The RO/RI Criterion routine then 
allocates to the requester's job step the 
region whose contents have been rolled out. 

If an error has occurred after a 
channel-end interruption,^ the Start Trans- 
fer routine branches to the Channel Program 
Initialization routine (CPINIT) to rein- 
itialize the channel programs. The Start 
Transfer routine then reissues the EXCP 
macro instruction to restart the channel 
programs. It thus makes a new attempt to 
transfer the region's contents. 

If an unrecoverable error has occurred, 
the Start Transfer routine issues an output 
message (lEAlOOl jobname stepname) . It 
then branches to do special processing that 
depends on whether rollout or rollin is 
being performed. If rollout is being per- 
formed, deferred I/O requests and deferred 
operator replies are restarted and the 
region is reallocated to its owning job 



^For this type of error the "lOB intercept" 
code appears in the completion code field 
of the ECB- 



step. A new attempt is then made to find a 
job step suitable to be rolled out. (See 
"Processing If I/O Error Occurred During 
Rollout.") If rollin is being performed, 
the job step that could not be rolled in is 
scheduled for abnormal termination, and 
queued rollout requests are restarted. 



Allocating the Borrowed Region to the 
Recpiestor* s Job Step 

If the Start Transfer routine (STARTIO) 
determines that there was no permanent 
error during rollout, it returns control to 
the RO/RI criterion routine. The RO/RI 
Criterion routine then does the following: 

• Issues a message to the operator in the 
form "IEA405I jobname, stepname, R/0 of 
jobname, stepname" . The routine issues 
the message by means of a WTO macro 
instruction and resulting supervisor 
linkage to the Write-to-Operator rou- 
tine (IGC0003E). 

• Disables I/O interruptions to prevent 
delay in returning control to the 
requester's task. 

• Reallocates to the requester's job step 
the region owned by the rolled-out job 
step. (The reallocation is done at 
symbolic location RR03.) The process- 
ing is similar to that previously 
described. (See "Processing If a Suit- 
able Job Step Can Be Found.") 

Processing if I/O Error Occurred During 
Rollout 

If the Start Transfer routine (STARTIO) 
determines that a permanent I/O error 
occurred during the attempted rollout, it 
branches to the Rollout Retry routine 
(RETRY) . The Rollout Retry routine 
restores to readiness the partially rolled 
out job step. It does this by: 

• Restarting the job-step's deferred I/O 
requests and operator replies, via the 
RSTRIO and RSTRQE routines. (See 
"Restarting Deferred I/O Requests for 
the Rolled-In Job Step" and "Restarting 
Deferred Operator Replies for the 
Rolled-In Job Step.") 

• Sets the "nonr oil out able" count 
(TCBNROC) for the job step, so that a 
new attempt to roll out the step will 
not be made. 

• Invokes the Set status routine (IGC079) 
to reset the "rollout nondispatchabili- 
ty" flag (TCBRFO) in each TCB of the 
job step. The Set Status routine is 
invoked via the STATUS macro 
instruction. 
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• Branches to the TESTSTEP routine to 
resume the search for a job step suit- 
able to be rolled out. The TESTSTEP 
routine gives control to the GETSTEP 
routine to search the TCB queue, as 
previously explained. (See "Obtaining 
a Job Step Suitable to Be Rolled Out.") 
If the GETSTEP routine can obtain a 
suitable step, the RO/RI Criterion rou- 
tine rolls out the selected step. If, 
however, the GETSTEP routine cannot 
obtain a suitable step, the RO/RI Cri- 
terion routine either schedules a job 
step for abnormal termination or places 
the current request on the rollout re- 
quest queue. (See "Processing If a Job 
Step Suitable for Rollout Cannot Be 
Found.") 

Exiting from the Rollout/Roll in Module 

The RETEXIT routine provides an exit 
from the RO/RI Module. It performs the 
following functions : 

• Places on the "next available" list the 
interruption queue element (IQE) that 
represents the current RO/RI request. 
The IQE is queued from the RBNEXAV 
field of the RO/RI IRB. This is done 
after the RO/RI module has been 
executed for any of its major func- 
tions: rollout, rollin, or scheduling 
of deferred rollout requests (IQEs) . 
This procedure is bypassed if rollout 
cannot be performed and the rollout re- 
quest is deferred. (See "Deferring the 
Current Rollout Request" in "Processing 
If a Job Step suitable for Rollout Can- 
not Be Found.") 

• Ensures a task switch by placing zero 
in the "new" TCB pointer (lEATCBP). 
This indication will cause the Dis- 
patcher to search the TCB queue for a 
ready task. 

• Issues an SVC 3 instruction to invoke 
the supervisor Exit routine (IGC003). 
The Exit routine dequeues the RO/RI IRB 
from the RO/RI TCB. This action makes 
the RO/RI task nondispatchable. The 
supervisor Exit routine then gains 
linkage to the Dispatcher, via the 
Transient Area Refresh routine. The 
Dispatcher searches down the TCB queue, 
starting with the RO/RI TCB, and dis- 
patches the current routine of the 
highest priority ready task. 



ALLOCATING SPACE IN THE SYSTEM QUEUE AREA 
AND LOCAL SYSTEM QUEUE AREA 

The system queue area is restricted to 
control program routines. Only those rou- 
tines that operate under a storage protec- 
tion key of zero can use space in this 



area. SQA can be requested by any task 
using subpools 243, 244 and 245 and by non- 
time sharing tasks using subpools 253, 254 
and 255. 



The local system queue area is also 
restricted to control program routines and 
serves the same purpose as SQA except that 
it is swapped with a time sharing user job. 
Only time sharing tasks can obtain LSQA 
space. Requests by time sharing tasks for 
subpools 253, 254, and 255 are allocated 
from LSQA by the GETMAIN routine. Time 
sharing tasks must request subpools 243, 
244 or 245 to obtain space in SQA. 



In addition to determining which area 
(SQA or LSQA) the space is allocated from, 
the subpool numbers also indicate which of 
the following characteristics should apply 
to the space: 



• Space within subpools 243 and 253, 
unless explicitly freed, is automatic- 
ally released when the task for which 
it is being used is terminated. 

• Space within subpools 244 and 254, 
unless explicitly freed, is released 
automatically when the job step for 
which it is being used is completed. 

• Space within subpools 245 and 255 must 
be freed explicitly with a FREEMAIN 
macro instruction. 

Before the system is generated, users of 
System/360 Operating System must specify 
the amount of space needed for a system 
queue area. During execution of the nucle- 
us initialization program, a descriptor 
queue element (DQE) containing a record of 
the number of 2048-byte blocks assigned to 
the system queue area is built within the 
area (see Figure 5-14) . Also built, adja- 
cent to the DQE, is a free queue element 
(FQE) that contains the number of bytes of 
available space (initially, all space is 
available) in the system queue area. Loca- 
tion GOVRFLB in the nucleus (pointed to by 
the secondary CVT) contains a pointer to 
the descriptor queue element; the descrip- 
tor queue element contains a pointer to the 
free queue element. 

The local system queue area is obtained 
and initialized when a time sharing region 
is started. The size of LSQA for each 
region is specified in the time sharing 
member of SYSl.PARMLIB. LSQA is contained 
within each time sharing region and is 
defined by the PQE for the region. An 
SPQE, DQE and FQE are built in the first 32 
bytes of LSQA and are initialized to define 
the available space in LSQA. 
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routine passes the address of a free area 
to the requesting routine in general 
register 1 if an SVC 10 instruction caused 
entry, or in a prespecified location if an 
SVC 4 instruction caused entry. No allo- 
cated queue element (AQE) is built. An AQE 
is not required, as it is the responsibili- 
ty of the requester to ensure that the 
space is freed with a FREEMAIN macro 
instruction. 



FREEMAIN ROOTINE 

The FREEMAIN routine services the 
FREEMAIN macro instruction, which is used 
to free space when it is no longer needed. 
Space assigned to a region, space within a 
region, space assigned to one or more bor- 
rowed regions, space in the system queue 
area, or space in the local system queue 
area may be freed. Basically, the FREEMAIN 
routine returns the allocated space to 
availability by adding queue elements 
representing the space to chains in which 
are recorded all free areas in main 
storage. 



Figure 5-lt. Element Relationships for 

System Queue Area Allocation 



Subpool 243 or 253 Allocation 

When subpool 243 or 253 is specified in 
the GETMAIN macro instruction, 8 bytes are 
added to the size requested, and the loca- 
tion of the beginning of the available 
space is determined. In the first 8 bytes 
of the requested area, the GETMAIN routine 
builds an allocated queue element (AQE) , 
into which it places the number of 
requested bytes, plus eight. It then chains 
the AQE to an AQE queue whose origin is in 
the TCB (TCBAQE field) of the task for 
which the space was requested. When that 
task is terminated. Supervisor termination 
routines scan the AQE queue and give a 
FREEMAIN macro instruction to free all 
space associated with subpool 243 or 253. 

Subpool 244 or 254 Allocation 

When subpool 244 or 254 is specified in 
a GETMAIN macro instruction, the GETMAIN 
routine builds an allocated queue element 
as it does for subpool 243 or 253, but 
chains the AQE to an AQE queue whose origin 
is in the job step TCB. When that job step 
is completed, supervisor termination rou- 
tines scan the AQE queue and give a 
FREEMAIN macro instruction to free all 
space associated with subpool 244 or 254. 

Subpool 245 or 255 Allocation 

When subpool 245 or 255 is specified in 
a GETMAIN macro instruction, the GETMAIN 



FREEING SPACE ASSIGNED TO A REGION 

To free a region, the TCBPQE field of 
the TCB that represents the task for which 
the region is being used is checked to 
determine the address of the partition 
queue element of the appropriate region. 
The space occupied by that partition qpieue 
element is then released (see the section 
"Freeing Space in Supervisor Queue Area"). 
Next, if the region to be freed is adjacent 
to an existing free area, it is combined 
with that area. This is done by adding the 
number of bytes in the region being freed 
to the size field of the free block queue 
element for the existing free area and, if 
necessary, relocating the FBQE to the 
beginning of the newly enlarged free area. 

If a region being freed is not adjacent 
to a free area, the FREEMAIN routine builds 
an FBQE for the area and adds it to the 
chain of FBQEs that represents all space 
available for allocation as regions. 

In a Model 65 Multiprocessing System, 
after a region has been freed, control is 
passed to the Vary Storage Offline routine 
(IFSVRYOF) which determines whether any of 
the freed region has been scheduled to be 
logically removed from the system because a 
VARY STORAGE OFFLINE command has been 
issued. The Vary Storage Offline routine 
checks for vary queue elements (VQEs) which 
are created when a VARY command is issued. 
If there are none, control is returned. 
Otherwise, the area of main storage speci- 
fied by each VQE is compared with that spe- 
cified by the freed PQE. For each VQE 



Section 5: Main Storage Supervision 129 



which applies to the freed area, the 
FBQE(s) and FSSEMAP are modified to indi- 
cate the area of main storage that has been 
made unavailable. (See Section 12, "Con- 
trol Blocks and Tables" for a description 
of FSSEMAP). The VARY task ECB is POSTed 
in each applicable VQE to indicate that a 
region within the range of that VQE has 
been processed. 

If the region being freed is not owned 
by the requester, it may be possible to 
roll in the job step that owns the region. 
In this case, the FREEMAIN routine branches 
to the FREBRF routine. This routine tests 
the region's attributes, and if possible, 
releases the region from the current job 
step and schedules linkage to the RO/RI 
module (lEAQRORI) . (For a description of 
the FREBRF routine, see "Freeing Space 
within a Region.") 



FREEING SPACE WITHIN A REGION 

TO free space within a region, the 
CSPCHK subroutine is used by the FREEMAIN 
routine to locate the subpool queue element 
(SPQE) representing the subpool from which 
space is to be freed. The address of the 
SPQE queue is contained in the TCBMSS field 
of the task control block associated with 
the task to which the space is assigned. 
The CSPCHK subroutine then determines 
whether any task(s) has been set non- 
dispatchable because of the limit on queue 
space. If any task(s) has been, it 
branches to the GETPART routine which 
attempts to reset the task(s) dispatchable. 
If not, the descriptor queue element that 
represents the area in which the space is 
to be freed is located. Next, the two free 
queue elements between which the space 
exists are located and a new free queue 
element (FQE) to represent the newly freed 
space is constructed. This FQE is either 
added to the chain of FQEs or, if the space 
lies adjacent to another free area, is com- 
bined with the FQE of the adjacent free 
area. 

A test is then made to determine if the 
resulting free area contains any free 20 t8- 
byte blocks of space that begin on a 2048- 
byte boundary. If it does, and the block 
is adjacent to an existing free 2048-byte 
block, the number of bytes to be freed are 
added to the count field in the FBQE repre- 
senting the existing free space and, if 
necessary, the FBQE is relocated. If the 
block being freed is not adjacent to any 
existing free 2048-byte block, a new FBQE 
is constructed. The number-of-bytes count 
in the appropriate DQE is then decremented 
to reflect the number of blocks being 
removed from the subpool. When this count 
reaches zero, the DQE is eliminated. 



If the System Management Facility (SMF) 
feature is present in the system, the 
FREEMAIN routine passes control to its SMF 
Storage subroutine (FMSMFCRE) . This rou- 
tine maintains storage usage information in 
the timing control table (TCT) . (If IBM 
2361 Core Storage is included in the sys- 
tem, storage information is maintained both 
for processor storage and for 2361 Core 
Storage. ) 



The SMF Storage routine checks the TCB 
for the address of the TCT. If there is no 
TCT , SMF Storage information is not being 
recorded for this user program. If there 
is a TCT, the SMF Storage routine performs 
the following functions: 

• It determines whether the newly 
released storage causes a change in the 
"low water mark" (LWM) or the "high 
water mark" (HWM) for the region. The 
LWM is the address of the highest 
storage address allocated from the bot- 
tom of the region, and the HWM is the 
address of the lowest storage address 
allocated from the top of the region. 
If either is changed, the SMF Storage 
routine stores the new value in the 
TCT. 

• If the rollout feature is included in 
the system and the storage being 
released is borrowed storage, the SMF 
Storage routine subtracts the amount of 
released storage from the record in the 
TCT of the current amount of borrowed 
storage. 

The SMF Storage routine returns control 
to the FREEMAIN routine. 

The freeing of space in the region may 
permit a rollin to occur, if the region was 
obtained through rollout. If the rollout 
feature is included in the system, the 
FREEMAIN routine branches to the FREBRF 
routine. This routine tests the region's 
attributes, and if possible, releases the 
region from the current job step and sched- 
ules linkage to the RO/RI module 
(lEAQRORI). 

The FREBRF routine performs the follow- 
ing functions for the job step whose space 
is being freed: 

• Examines the partition queue element 
(PQE) that describes each region allo- 
cated to the job step. 

• Determines if the region is "borrowed" 
and "free." The region is borrowed if 
its PQEBOR flag is set, indicating that 
the region is not owned by the job 
step. The region is "free" if none of 
its space is assigned to a subpool. 
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• If the region is borrowed and free, 
does the following: 

1. Releases the region from the cur- 
rent (borrowing) job step. It does 
this by removing the PQE from the 
current job- step's PQE queue. 

2. Schedules linkage to the RO/RI 
module to attempt the rollin of the 
job step that owns the region. 
This is done via a branch to the 
SCHEDRRI routine. 

3. Determines if the region was allo- 
cated from unassigned space in the 
dynamic area. (Such a condition is 
indicated by zero in the PQETCB 
field.) 

4. Frees the region, if it was allo- 
cated from unassigned space, via a 
branch to the MRELEASE routine. 

5. If the multiprocessing feature was 
selected, and the region was allo- 
cated from unassigned space, deter- 
mines if any part of the region is 
to be removed from available main 
storage via a branch to the Vary 
Storage Offline routine (IFSVRYOF) . 
(For a description of the Vary 
Storage offline routine, see "Free- 
ing Space Assigned to a Region.") 

If rollin is warranted, the SCHEDRRI 
routine schedules linkage to the RO/RI 
module. The routine's processing is simu- 
lar to that of the SHEDRO routine, which 
schedules the RO/RI module to perform roll- 
out. (See "Scheduling Linkage to the 
Rollout/Rollin Module" in "Processing If 
the Requested Space Is Not Available.") 



FREEING ONE OR MORE BORROWED REGIONS 
THROUGH ROLLIN 

The RO/RI module is entered at location 
lEAQRORI from the Dispatcher, when it dis- 
patches the RO/RI task via a Load PSW 
instruction. The RO/RI module determines 
that rollin is needed by observing that the 
input parameter-list address is negative. 
Accordingly, it branches to the RO/RI Cri- 
terion routine. 

The RO/RI routine (ROLLIN) coordinates 
all functions performed during rollin. 
These functions consist of: 

• Freeing the space occupied by the bor- 
rowing job-step's PQE. 

• Determining whether the rolled out job 
step should be rolled in. 



• Transferring the rolled out job step to 
main storage, if the step should be 
rolled in. Performs special processing 
if I/O error occurred during the 
transfer. The processing consists of 
reconstructing free block queue ele- 
ments (FBQEs) and scheduling the 
abnormal termination of the partially 
rolled-in step. 

• Restarting deferred I/O requests for 
the rolled-in step. 

• Restarting deferred operator replies 
for the rolled-in step. 

• Making dispatchable the tasks of the 
rolled-in step. 

• Performing final common housekeeping, 
primarily for the borrowing job step. 

• Scheduling rollout for deferred rollout 
requests. 

Freeing the Borrowing Job Step's PQE 

The RO/RI Criterion routine first saves 
from the borrower's PQE the addresses of 
the region and the owner's job step TCB. 
It then invokes the FREEMAIN routine 
(IGCOIO) , via supervisor linkage. The 
FREEMAIN routine frees the space occupied 
by the borrower's PQE, since this PQE is no 
longer needed. There is now only one PQE 
that describes the region, the owner's PQE. 

Determining Whether the Rolled-Out Job Step 
Should Be Rolled In 

To determine whether the rolled out step 
should be rolled in, the RO/RI Criterion 
routine does the following: 

• Determines if the region was allocated 
to the borrower by means of a rollout, 
or whether the region was allocated 
from free space in the dynamic area. 
(If the region was allocated from free 
spacei, the owner's TCB address in the 
PQE (PQETCB) is zero.) 

• Branches to location RIN08 to do final 
housekeeping, bypassing rollin, if the 
region was allocated from free space. 
(See "Performing Final Common 
Housekeeping . " ) 

• Determines if any of the owner's PQEs 
represent the region that is being 
freed. ^ If so, clears the "in use" flag 
(PQEOSE) in the PQE to indicate that 



^A rolled out step normally has only one 
PQE and region, since rollout of a step 
that has itself caused rollout is 
forbidden. 
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the region is not being used by a 
borrower. 



• Bypasses rollin if the ovming job step 
has any borrowed region that is still 
in use. In this case, the RO/RI Crite- 
rion routine branches to location RIN08 
to perform final housekeeping. If, 
however, the owning step has no bor- 
rowed region that is still in use, the 
routine begins the rollin of the step. 



Transferring the Rolled-Out Job Step to 
Main Storage 

The RO/RI Criterion routine transfers to 
main storage the contents of the job-step's 
region (s). It also does some housekeeping. 
For each region whose contents are to be 
rolled in, the routine does the following: 

• Changes the storage protection key of 
all 2K blocks from the borrower's key 
to that of the owner, except subpools 
which are given their protection key. 
This is done via a branch to location 
SETKEYSl. 

• Branches to the Start Transfer routine 
(STARTIO) to enable I/O interruptions 
and transfer the region's contents to 
main storage. (See "Transferring the 
Contents of the Selected Region to the 
Rollout Data Set.") 

• Writes the rollin message "IEA406I job- 
name, stepname, ROLLIN," if permanent 
I/O error did not occur during the 
transfer. The message is written via 
the Write-to-Operator routine 
(IGC003E) . 

• Disables I/O interruptions and tests 
for I/O error during the transfer. If 
there was permanent I/O error, the job 
step cannot be returned to its region. 
The RI/RO Criterion routine, in this 
case, reconstructs the free block queue 
elements (FBQEs) of the region, so that 
invalid FBQEs will not cause an ABEND 
recursion when the job step is abnor- 
mally terminated. The reconstruction 
is accomplished through the use of the 
MRELEASE routine in module lEAQMOO. 

• Resets the "rollout" flag (PQERO) in 
the owner's PQE to indicate that the 
region's contents are not rolled out. 

• Sets the free 2K blocks of the region 
to zero protection key. This is done 
so that the blocks may not be used by 
the job step until they have been allo- 
cated by the GETMAIN routine. (Sets 
zero protection key by branching to 
location SETKEYS.) 



• If there was permanent I/O error during 
the transfer, branches to location 
ERRIN to invoke the supervisor's ABTERM 
routine. This routine schedules the 
abnormal termination of the partially 
rolled-in job step. As part of the 
abnormal termination, the ABEND routine 
(ABEND16) frees the region's space, via 
the Release Main Storage routine (lEAQ- 
SPET) . The ABTERM routine returns con- 
trol to location RIN06 in the RO/RI 
module. (See "Making Dispatchable the 
Tasks of the Rolled- In Job Step.") 

• Calls the TCAM Post Pending routine 
(IGG019RQ) when there is an OS Post 
pending for a task that is currently 
being rolled in. 

Restarting Deferred I/O Requests for the 
Rolled-In Job Step 

The RO/RI Criterion routine uses its SVC 
Restore Interface routine (RSTRIO) to 
restart I/O requests belonging to the 
rolled-in job step. These I/O requests 
were deferred when the job step was rolled 
out. (See "Processing If a Suitable Job 
Step Can Be Found.") 

For each task of the rolled-in step, the 
SVC Restore Interface routine does the 
following: 

• Selects the task's TCB address from a 
rollout I/O queue element (RIQE) on the 
RIQE queue. (See Section 12, "Control 
Blocks and Tables, " for the RIQE 
format.) 

• Prepares for the redispatching of the 
SVC Restore Interface routine under 
control of the selected TCB- The I/O 
Supervisor associates the restored I/O 
requests with the TCB under which the 
RESTORE macro instruction is issued. 
The preparation consists of: 

1. Dequeuing the RO/RI IRB from the 
RO/RI TCB (or from a previously 
selected TCB) , and placing it at 
the head of the RB queue of the 
selected task. The shifting of the 
IRB makes the RO/RI task 
nondispatchable. 

2. Sets the "prevent asynchronous 
exits" flag (TCBFX) in the selected 
TCB. The purpose is to prevent the 
scheduling of an asynchronous exit 
routine by the Stage 3 Exit Effec- 
tor when the Dispatcher is entered. 
Such scheduling would interfere 
with the issuance of the RESTORE 
macro instruction. 

3. Places in the IRB old PSW the reen- 
try address (RSTRIO 4) of the SVC 
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Restore Interface routine. This 
address is the point at which the 
routine is redispatched to issue 
the macro instruction. 



H. Makes the selected task temporarily 
dispatchable by clearing nondis- 
patchability flags in its TCB. 
(The TCBFRO flag was set in each 
TCB of the job step during rollout 
processing.) The flags are saved 
so that they may later be restored. 

5. Saves the register contents that 
were stored in the selected TCB. 
Stores the RO/RI module's register 
contents in the selected TCB. This 
is necessary because the Dispatcher 
always loads registers from the TCB 
whose task it will dispatch. 

6. Indicates to the Dispatcher that it 
should dispatch the selected task. 
The routine does this by zeroing 
the "new" TCB pointer (lEATCBP) and 
invoking the supervisor's Task 
Switching routine. The Task 
Switching routine, detecting that 
the RO/RI task is nonready, places 
the selected TCB address in the 
"new" TCB pointer. 

• Branches to the Dispatcher to redis- 
patch the SVC Restore Interface routine 
at location RSTRI04. 

• Issues the RESTORE macro instruction, 
specifying the list origin (RIQEIOB) of 
a chain of lOBs. The lOBs represent 
channel programs deferred during roll- 
out. The RESTORE macro instruction 
causes supervisor linkage to the I/O 
Supervisor, which sets I/O request ele- 
ments to schedule the channel programs. 

• Dequeues the RIQE for the selected task 
and frees its storage space (via the 
FREEMAIN routine) , since the RIQE is no 
longer needed. 

• Restores the selected task to its pre- 
vious status by restoring its saved 
"prevent asynchronous exits" flag and 
its nondispatchability flags. Places 
the task's saved general register con- 
tents in the selected TCB- 

When it has issued the RESTORE macro 
instruction for all tasks of the job step, 
the SVC Restore Interface routine causes 
the redispatching of the RO/RI task, as 
follows : 

• Dequeues the RO/RI IRB from the last- 
selected TCB and queues it from the 
RO/RI TCB. This action makes the RO/RI 
task ready. 



• Places the return address (RSTRI06) of 
the SVC Restore Interface routine in 
the IRB old PSW, in preparation for the 
redispatching of the RO/RI task. 

• Places the RO/RI module's saved regis- 
ter contents in the RO/RI TCB. The 
Dispatcher loads the registers from 
this TCB. 

• Branches to the Task Switching routine 
with the address of the RO/RI TCB. It 
does this to indicate to the Dispatcher 
that it should next dispatch the RO/RI 
task instead of the last-selected task. 

• Branches to the Dispatcher to redis- 
patch the RO/RI task. When redis- 
patched (at location RSTRI06) , the SVC 
Restore Interface routine returns con- 
trol to the RO/RI Criterion routine. 

Restarting Deferred Operator Replies for 
the Rolled- In Job Step 

The RO/RI Criterion routine branches to 
the Reply Restore routine (RSTRQE) to 
restart operator replies that were received 
while the step was rolled out. The Reply 
Restore routine examines each reply queue 
element on the reply queue. Each element 
represents an operator reply that either 
was received or will be received. (The 
origin of the reply queue is UCMRPYQ in the 
unit control module. ) The Reply Restore 
routine performs as follows for each reply 
queue element that is flagged "rolled out" 
and which belongs to the rolled-in step: 

• Clears the "rolled out" flag (RQERO) in 
the reply queue element. (This flag 
was set by the Reply Purge routine 
(PRGRQE) when the step was rolled out.) 
The cleared flag indicates to the com- 
munications task Reply Processor rou- 
tine (IGC1203D) that it may move the 
reply to the user's buffer. 

• Tests the "temporary-buffer" pointer 
(RQEXB) in the reply queue element. 
(In the program listing, it is called 
the "purging message address.") If the 
pointer is nonzero, the Reply Processor 
routine received a reply and placed it 
in the temporary buffer, while the job 
step was rolled out. 

• Issues an MGCR macro instruction to 
restart the reply, if it was received 
while the job step was rolled out. The 
macro instruction causes supervisor 
linkage to the Reply Processor routine 
(IGC1203D) , via the Command Processing 
routine and the MGCR Router routine. 
The Reply Processor routine determines 
that the temporary buffer is full 

(RQEXB is nonzero) , moves the reply to 
the user's buffer, frees the temporary 



Section 5: Main Storage Supervision 133 



buffer, and completes the processing of 
the reply. (See "Reply Processing" in 
Section 7, "Console Connnunications and 
System Log.") 

Continues the examination of the reply 
queue until all reply queue elements 
that belong to the rolled-in step have 
been processed. The routine begins 
each new scan at the reply queue ori- 
gin, because the Reply Processor rou- 
tine reorders the queue each time that 
it is entered. 

Returns control to location RIN06 in 
the RO/RI Criterion routine. 



Making Dispatchable the Tasks of the 
Rolled- In Job Step 

The RO/RI Criterion routine next makes 
dispatchable the tasks of the rolled-in job 
step if all the regions, in both hierarchy 
and 1, belonging to the task are in 
storage. (These tasks were set nondis- 
patchable during rollout by the RO/RI Cri- 
terion routine, just before it deferred the 
job step's I/O requests.) 

The RO/RI Criterion routine (at location 
RIN06) issues the STATUS macro instruction 
to cause supervisor linkage to the Set sta- 
tus routine {IGC079) . This routine clears 
the "rolled out" nondispatchability flag 
(TCBFRO) in each TCB of the step. 

The operands of the STATUS macro 
instruction, as used above, have these 
meanings: 



I RESET, ND 



(6) 



(12) 



-+- 



(Causes the 
I clearing of 
I the nondis- 
1 patchability 
I flag speci- 
jfied by the 
I mask operand 
I (12). 



Indicates that] This mask 
the TCB whose [number indi- 
address is in |cates that 



register 6 
(JSTREG) and 
its descen- 
dants are to 
be reset as 
specified. 



J the "rolled 
I out" nondis- 
I patchability 
I flag (TCBFRO) 
I should be 
I cleared. 



Performing Final Common Housekeeping 

The RO/RI Criterion routine next per- 
forms final common housekeeping, primarily 
for the borrower's job step. The house- 
keeping, begun at location RIN08, is common 
to three types of rollin: 

1. A rollin of a job step that is com- 
pleted without I/O error. 

2. An attempted rollin of a job step that 
has produced a permanent I/O error. 



3. A rollin to a region that was allo- 
cated from free space in the dynamic 
area. 

The common housekeeping consists of: 

• Decreasing by a count of one the "roll- 
outs invoked" counter (ROICTR) to indi- 
cate that the current rollout is no 
longer in effect. The RO/RI Criterion 
routine tests the count each time a 
rollout is requested. Unless permitted 
by a user appendage (lEAQAPGl) the 
RO/RI Criterion routine will prevent 
another rollout (defer the request) if 
the count equals one. 

• Clearing the "rollout invoked" flag 
(TCBFRI) in the borrower's job step 
TCB, if the job step has no other bor- 
rowed regions. The flag is tested by 
the TESTSTEP routine during rollout 
processing, to determine if a selected 
job step has invoked rollout. A job 
step is not suitable to be rolled out 
if it has itself invoked rollout. 

The RO/RI Criterion routine then 
branches to its Dequeue routine to schedule 
rollout for deferred rollout requests. 

Scheduling Deferred Rollout Requests 

A rollout request (IQE) was deferred 
during rollout and placed on the rollout 
request cpaeue for either of two reasons: 
another rollout was in effect and concur- 
rent rollouts were prohibited, or a job 
step suitable to be rolled out could not be 
found. 

Deferred rollout requests are scheduled 
by the RO/RI module's Dequeue routine 
(DEQUEUE) - This routine is entered either 
from the RO/RI Criterion routine, via a 
branch, or from the Set Status routine 
(IGC079), during scheduling of the RO/RI 
module. In either case, a new region is 
available for rollout. 

The Dequeue routine schedules deferred 
rollout requests as follows: 

• Stores zero in the pointer to the roll- 
out request queue (lEAROQUE). It does 
this because the queue is being tem- 
porarily eliminated. 

• Places zero in the count of deferred 
rollout requests (lEAROQCT). During 
rollout this count can be used by an 
optional user appendage (IEAQAPG3) to 
determine whether to abnormally termi- 
nate a job step, if a step suitable for 
rollout cannot be found. 

• If there are no IQEs on the rollout 
request queue, branches to the RETEXIT 
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routine to queue the current IQE to the 
"next available list" (RBNEXAV) and 
exit from the RO/RI module. (See 
"Exiting from the Rollout/Rollin 
Module.") 

If there is at least one IQE on the 
rollout request queue, does the follow- 
ing for each IQE: 

1. Complements the IQE address to 
serve as an input parameter for the 
Stage 2 Exit Effector. This indi- 
cates to Stage 2 that the element 
is an IQE, not an I/O request ele- 
ment. (Stage 2 handles both types 
of elements.) 

2. Clears the "wait for core" nondis- 
patchability flag (TCBWFC) in the 
requestor's TCB. (This TCB is the 
one whose address is contained in 
the IQE.) The flag is cleared 
because the task's main storage 
request is being reactivated. 

3. Branches to the Stage 2 Exit Effec- 
tor (lEAOEFOO) with the comple- 
mented IQE address. Stage 2 sched- 
ules linkage to the RO/RI module 
for the request. It does this by 
placing the IQE on one of the asyn- 
chronous exit queues (AEQJ) . (See 
"Scheduling Linkage to the Rollout/ 
Rollin Module" in "Processing If 
the Requested Space Is Not 
Available.") 

Branches to the RETEXIT routine, when 
all IQEs on the rollout request queue 
have been scheduled. (See "Exiting 
from the Rollout/Rollin Module.") 



FREEING SPACE IN THE SYSTEM QUEUE AREA AND 
LOCAL SYSTEM QUEUE AREA 

To free space in the system queue area 
or in the local system queue area, the 
FREEMAIN routine determines whether space 
within subpools 2'»3 or 253 and 244 or 254 
is to be freed. If so, 8 bytes are added 
to the size of the area to be freed (to 
include the AQE that is contained in the 
area) , and 8 bytes are subtracted from the 
address of the space. 



For subpools 243, 244, 253 and 254, the 
address of the appropriate AQE is obtained 
from the TCBAQE field of the associated 
TCB. If the entire area defined by the AQE 
is to be freed, the AQE is simply removed 
from the AQE queue. Otherwise, it is 
altered by changing its byte count. 



When address correction has been com- 
pleted or if the FREEMAIN request is for 
subpools 245 or 255, a check is made to 
ensure that the specified area falls within 
the bounds of SQA or LSQA as applicable. 

The DQE for the area is then obtained 
and an FQE is built for the area being 
freed and is placed on the DQE FQE chain. 
Any resulting contiguous free areas are 
combined by combining FQEs. 

For non-time sharing tasks, subpools 
243, 244, 245, 253, 254, and 255 all free 
SQA space. For time sharing tasks, sub- 
pools 243, 244 and 245 free SQA space and 
subpools 253, 254, and 255 free LSQA space 
(or SQA space if LSQA has overflowed into 
SQA). 
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SECTION 6: TIMER SUPERVISION 



SYSTEM/360 TIMER SUPERVISION 

The Timer Supervision routines extend 
the capabilities of the IBM Systein/360 
interval timer feature. By using the 
timer,, these routines service the macro 
instructions by which programmers can 
obtain the date and time of day, measure 
periods of time, or schedule activity for a 
specific time of day . 



The need for timer services is always 
signaled by an interruption, after which 
control is automatically given to an appro- 
priate timer supervision routine. SVC 
interruptions occur when a TIME, STIMER, or 
TTIMER macro instruction is executed, and 
timer interruptions occur »*ien a value in 
the interval timer expires. After an SVC 
interruption, one of three macro service 
routines is given control. 



The TIME routine supplies the current 
date and time of day . The operator ini- 
tially gives a starting date and time of 
day with a SET command. Thereafter, Timer 
Supervision routines change the date at 
midnight and keep track of elapsed time. 
The TIME routine obtains the current date, 
adds elapsed time to the starting time 
given by the operator, and returns both 
values in general registers. 

The STIMER routine processes requests 
for timed intervals by scheduling their 
placement into the interval timer to cause 
interruptions at requested times. For each 
STIMER macro instruction, this routine 
builds a queue element and places into it a 
suTiimary of the information in the STIMER 
macro instruction, including the informa- 
tion that will be needed when the interval 
expires. It then positions the element in 
the timer queue by its time of expiration. 
When a timer interruption occurs (a value 
in the timer expires) , timer interruption 
handling routines perform any requested 
actions and obtain new intervals to be 
placed into the timer from elements in the 
timer queue. 

The TTIMER routine supplies the time 
remaining in a previously requested inter- 
val or it cancels previous requests for 
remaining time. To determine remaining 
time, the TTIMER routine subtracts elapsed 
time from the time of expiration of the in- 
terval. To cancel previous requests, the 
TTIMER routine removes corresponding ele- 
ments from the timer queue. 



In a Model 65 Multiprocessing System, 
each CPU has an interval timer located in 
its prefixed storage area (PSA) . One timer 
is designated as active and is used by tim- 
ing routines; the second, or alternate, 
timer is always set to a value X' 80000000' 
greater than the active timer and thus 
never expires. If the CPU is in partioned 
mode, or is the only online CPU in a Model 
65 Multiprocessing System, the alternate 
timer is set, but does not decrement. 
Timer routines access the interval timer by 
adding the PSA displacement value of the 
timer to the value in PREFTMRA, an index to 
the PSA that contains the active timer. 
PREFTMRA is a PSA word which contains zeros 
if the active timer is in the same PSA, or 
the address of the other PSA if the timer 
is located in the other PSA. 



SYSTEM/370 TIMER SUPERVISION 

Control programs executing on System/370 
CPUs use the interval timer feature and the 
Time-of-Day (TOD) Clock, a standard feature 
on these CPUs which provides timing resolu- 
tion to one microsecond. In the following 
description of timer supervision, dif- 
ferences with the System/370 Time-of-Day 
Clock, if any, are discussed immediately 
after the descriptions of each timer rou- 
tine or function. 

The operator need reset the clock only 
when the current date and time of day are 
incorrect, not at each IPL. The TOD Clock 
runs continuously while power is on. 

Because the TOD clock maintains elapsed 
time automatically (using 0000 hours, 
January 1, 1960 as the base), the TIME rou- 
tine uses the TOD Clock to update, when 
necessary, the current date and to deter- 
mine the time of day. The current date and 
time of day are returned to the caller in 
the manner specified in the TIME macro 
instruction. 

When the requested interval is greater 
than one hour, the STIMER routine uses the 
TOD Clock to determine the value expected 
to be in the TOD Clock at expiration. When 
the requested interval is less than or 
equal to one hour, System/360 processing is 
used. 

To determine the time remaining in an 
interval, the TTIMER routine subtracts the 
value in the TOD Clock from the value 
expected to be in the TOD Clock at 
expiration. 



136 



TIMER SVC INTERRUPTION HANDLING 

The handling of interruptions resulting 
from issuance of timer-related macro 
instructions, is shown in Figure 6-1. 

The expansions of the TIME, STIMER, and 
TTIMER macro instructions contain SVC 11, 
SVC 47, and SVC 46 instructions, respec- 
tively. When these SVC instructions are 
executed, SVC interruptions occur and con- 
trol is given to the SVC First-Level Inter- 
ruption Handler, which saves information 
about the interrupted program and routes 
control accordingly. 

Both the TIME and TTIMER routines are 
type-1 SVC routines, and control is given 
directly to them by the SVC First-Level 
Interruption Handler. The STIMER routine, 
however, is a type-2 SVC routine, and con- 
trol is first given to the SVC Second-Level 
Interruption Handler, which creates a 
supervisor request block, places into it 
the information about the interrupted pro- 
gram, and then gives control to the STIMER 
routine. (For a complete description of 
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SVC first-level and second-level interrup- 
tion handling, see "SVC Interruption Han- 
dling" in Section 2.) 

After type-1 SVC routines have been 
executed, control is given to the Type-1 
Exit routine, which determines whether the 
task for which the SVC instruction was 
given should be resumed. If so, the Type 1 
Exit routine restores the saved contents of 
registers and returns control to the rou- 
tine in which the SVC instruction was 
encountered. If another task is to be per- 
formed, the Type-1 Exit routine saves 
register contents in the appropriate TCB, 
saves the contents of the old PSW in the 
appropriate request block, and gives con- 
trol to the Dispatcher. 

After type-2 SVC routines have been 
executed, control is given to the Exit rou- 
tine, which performs functions similar to 
the Type-1 Exit routine and also gives con- 
trol to the Dispatcher. 

The Dispatcher routes control to the 
highest priority task that can be 
performed. 



THE TIME ROUTINE IN SYSTEM/360 

The TIME routine determines the current 
date and time of day and returns both 
values to requesting routines in general 
registers. It obtains the date from a 
location in the communication vector table, 
into which it was placed by the Job Manage- 
ment SET Command routine. (Each day at 
midnight, the date is changed by the Timer 
Second-Level Interruption Handler.) To 
determine the time of day, however, the 
TIME routine must first determine how much 
time has elapsed since the operator gave 
the SET command. 

After the operator gives a starting 
time, the interval timer must be kept con- 
tinually operating, so that an elapsed time 
can be measured. The interval timer auto- 
matically decrements any value placed into 
it and causes an interruption when the 
value becomes negative. For timekeeping 
purposes, 6-hour intervals are used. Dur- 
ing initial program loading (IPL) , a 6-hour 
value is placed into the interval timer, 
and, when this value expires, another 6- 
hour interval is placed into the timer by 
the Timer Second-Level Interruption Han- 
dler. 

To measure elapsed time, two pseudo 
clocks are used with the interval timer. 
Each time a 6 -hour value is placed into the 
timer, one is also placed into a 6-hour 
pseudo clock. However, the value in the 
timer decrements, while that in the 6-hour 
pseudo clock does not. Thus, an elapsed 
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time of up to 6 hours can be determined by 
subtracting the value in the timer from 
that in the 6-hour pseudo clock. 

To measure intervals longer than 6 
hours, a 6-hour value is added into a 2H- 
hour pseudo clock each time one is placed 
into the 6-hour pseudo clock except for the 
first 6-hour interval. (Each time a 24- 
hour period elapses, the 24-hour pseudo 
clock is reset to 0.) The TIME routine 
determines elapsed time by subtracting the 
value in the timer from the sum of the 
values in the 6-hour pseudo clock (SHPC) 
and the 24-hour pseudo clock (T4PC) : 

Elapsed Time = (SHPC + T4PC) - Timer 

Elapsed time is added to the starting time 
given by the operator to arrive at the cur- 
rent time of day. 

The values used in the timer are timer 
units equalling 13 microseconds; the values 
used in the pseudo clocks are timer units 
equalling 26.04166 microseconds. Timer 
values are converted to units of 26.04166 
microseconds for calculations. The TIME 
routine converts the time of day to packed 
decimal form if the decimal (DEC) option 
was specified in the TIME macro instiniction 
or to an unsigned binary value, if the 
binary (BIN) option was specified. If the 
timer units (TU) option was given, no conv- 
ersion is performed. The current time of 
day is returned to requesters in general 
register 0, and the date is returned in 
general register 1. 



THE TIME ROUTINE IN SYSTEM/370 

With the TOD Clock, an additional para- 
meter (MIC, address) is used to obtain the 
time of day in microseconds. The date is 
obtained from the CVT, as in System/360 
processing, but all calculations to deter- 
mine the time of day are performed in 
microseconds. 

Each time that the TIME routine 
(lEAORTOl) is entered, the current date is 
verified using the value in the TOD Clock. 
The MNIGHT field in the nonexecutable timer 
module lEACVTPC contains the value that is 
expected to be in the TOD Clock at midnight 
of that day. From the MNIGHT value, the 
TIME routine subtracts the current value in 
the TOD Clock. If the result is positive, 
midnight of that day has not been reached 
and the current date is correct. If the 
result is or negative, midnight of that 
day has been passed. The current date in 
the CVT is incremented by one day, the 
MNIGHT value is incremented by 24 hours (in 
microseconds) , and the synchronization 
indicator in the midnight element is set 
on. Because the variance in the current 



date may have been more than one day, the 
procedure described above is repeated until 
the result of the subtraction is positive. 

The TIME routine does not calculate the 
time of day in a manner similar to the TIME 
routine in System/360. Instead, the TIME 
routine uses the TOD Clock and the follow- 
ing algorithm to calculate the time of day 
in microseconds: 

TOD = 86.4 X 10» - (MNIGHT - CLOCK) 

where 86.4 x 10' is the number of micro- 
seconds in one day. 

MNIGHT is the value expected to be 
in the TOD Clock at midnight 
of the current day. 

CLOCK is the current value of the 
TOD Clock 

(MNIGHT - CLOCK) yields the number 
of microseconds remaining 
until midnight of the cur- 
rent day. 

For a time of day request specifying the 
MIC operand, the user-specified address is 
checked for validity. If the address is 
invalid, register is set to 0, register 1 
contains the date, the specified location 
is unchanged, and control is returned to 
the caller with a code of 4 in register 15. 
For a valid address, register 15 is set to 

0, the current date is returned in register 

1, and the time of day is returned in the 
doubleword field specified by the caller; 
register is set to 0. 

If the TU operand was specified, the 
calculated time is converted to timer units 
by dividing the microsecond value by 
26.04166. If the BIN or DEC operands were 
specified, the calculated time is divided 
by 10000 and the result is returned if BIN. 
If DEC was specified, the result is con- 
verted to HHMMSSth format. 

Note: If the TIME routine is entered 
before nucleus initialization is complete, 
the date is returned as X'OOOOOOOF' and the 
time is returned as 0. 



STIMER ROUTINE 

The STIMER routine builds and positions 
on the timer queue the elements that repre- 
sent time intervals requested with STIMER 
macro instructions. If necessary, this 
routine first converts requested time from 
hours, minutes, and seconds to timer units. 
Then, using either an existing element or 
creating a new one, it places into the ele- 
ment information specified in the STIMER 
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macro instruction. Finally, it uses the 
Timer Enqueue subroutine to position the 
elements on the timer queue. 



The Timer Queue in System/360 

The timer queue provides a means of 
scheduling values representing time inter- 
vals for placement into the interval timer 
to cause interruptions to occur at appro- 
priate times. 



All elements in the timer queue are 
arranged by a time of expiration. After a 
timer interruption, the topmost element 
always represents the expired interval. 
This element is removed from the queue and 
used to determine what action is to be 
taken. Meanwhile, the interval represented 
by the next element is placed into the in- 
terval timer, and the procedure begins 
again. 



The time of expiration, by which ele- 
ments are ordered on the timer queue, is 
based on a 6-hour cycle. The STIMER rou- 
tine places the interval requested in the 
element and uses the timer enqueue routine 
in the Timer SLIH to convert the interval 
to a time of expiration and to place the 
element on the timer queue. The timer 
enqueue routine subtracts the value in the 
interval timer from the value in the 6-hour 
pseudo clock (SHPC) and adds the interval 
requested: 

TOX = (SHPC - Timer) + interval requested 

For example, assume that no requests are 
pending and that 3 hours have elapsed since 
the operator issued a SET command. Figure 
6-2 shows the timer queue and the values in 
both the timer and the 6- hour pseudo clock 
at this time. Assume now that an STIMER 
macro instruction requests a timer inter- 
iniption in 5 hours. The time of expiration 
(TOX) is determined: 

TOX = (SHPC - Timer) + interval requested 
8 = ( 6 - 3 ) + 5 

The element representing the 5-hour 
request is positioned on the timer queue 
between the 6-hour and midnight elements. 
Both the 6-hour and midnight elements 
always exist on the queue. When the 6-hour 
element expires, the Timer Second-Level 
Interruption Handler subtracts 6 hours from 
the times of expiration of all other ele- 
ments on the timer queue and repositions 
the 6 hour element. Thus the element 
representing the request then becomes the 
topmost element, and its 2-hour time of 
expiration is placed into the interval 
timer. A timer interruption occurs on 
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schedule — 5 hours after receipt of the 
request. When the midnight element 
expires, the Timer Second-Level Interrup- 
tion Handler changes the date given by the 
operator and repositions the midnight 
element. 

The Timer Queue in System/370 

The timer queue in System/370 is similar 
to that in Systen/360. However, the STIMER 
routine uses the TOD Clock to process REAL 
and WAIT type requests when the interval 
specified is greater than one hour. (REAL 
and WAIT type requests for intervals less 
than or equal to one hour and TASK type 
requests are processed as in System/360.) 
STIMER converts the requested interval from 
timer units to 1.0t8576-second units and 
adds the resulting value to the current 
value in the TOD Clock. (Bit 31 in the TOD 
Clock is incremented every 1.0'»8576 
seconds. Microsecond values are indicated 
by bit 51.) This yields the expected value 
of the TOD Clock at the time of expiration 
of the specified interval. This value is 
saved in the TQEWORK field in the element 
and will be used by the timer SLIH each 
time that the one- hour interval for this 
element expires (see "Determining What 
Actions Are to be Performed in System/370" 
below) . STIMER places an interval of one 
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hour (in timer units) in the field TQEVAL 
in the element, sets on the synchronization 
indicator in the element, and uses the 
timer enqueue routine in the timer SLIH to 
convert the interval from timer units to a 
time of expiration and to place the element 
on the timer queue. Although the interval 
specified was greater than one hour, a 
timer interruption occurs in one hour and 
the element is examined by the timer SLIH 
for further processing (see "Timer Inter- 
ruption Handling" below) . 

Determining Interval Values in System/360 

The STIMER macro instruction allows the 
user to specify the time interval in one of 
four ways : decimal form ( DINTVL) , binary 
form (BINTVL) , timer units (TUINTVL) , and 
time of expiration (TOD) • When decimal or 
binary form is given, the STIMER routine 
converts the value to timer units (one 
timer unit = 26.04166667 microseconds), 
before using the timer enqueue routine. 
When timer units are given, no conversion 
is necessary. 

When time of expiration (TOD) is speci- 
fied in the STIMER macro instruction, STIM- 
ER converts the time to an interval by sub- 
tracting the current time of day from the 
specified time of expiration. The interval 
is converted to timer units before using 
the timer enqueue routine. The current 
time of day is determined using the follow- 
ing algorithm: 

Current Time of Day = LTPC + T4PC + (SHPC - 
Timer) 

where: 

LTPC = Starting time given by the operator 
in the SET command. 

Tit PC = Value in the 24-hour pseudo clock. 

SHPC = Value in the 6 -hour pseudo clock - 

Timer = Value in the timer. 

If the specified time of expiration is the 
same as the current time or has already 
passed, the calculation of the time of 
expiration results in either zero or a 
negative number. To this calculated 
expiration time (zero or a negative num- 
ber) , the STIMER routine adds 24 hours. 

Because no interval that exceeds 24 
hours is valid, the STIMER routine replaces 
any interval that exceeds 24 hours with a 
24-hour interval. 

Determining Interval Values in Svstem/370 

The DINTVL, BINTVL, and TUINTVL operands 
are processed in a manner identical with 



System/360. When a time of expiration 
(TOD) is specified as the operand in a 
STIMER macro instruction, the STIMER rou- 
tine uses the TOD Clock to determine the 
interval. STIMER first converts the time 
of expiration to a value in timer units 
that represents the interval between the 
beginning of that day (0000 hours) and the 
specified time of expiration. From this 
value, STIMER then subtracts the current 
time of day in timer units. The current 
time of day in timer units is calculated 
using the following algorithm: 

TOD = (82397 - [MNIGHT - CLOCK]) x 40265 

where MNIGHT is the value expected to be 
in the TOD Clock at midnight 
of that day. 

CLOCK is the current value of the 
TOD Clock. 

If the specified time of expiration has 
already been passed (the interval value is 
negative) , STIMER adds the number of timer 
units in one day to the interval so that 
the time of expiration will occur at the 
specified time on the next day. 

Building Timer Queue Elements 

The STIMER routine builds queue elements 
using information provided by the program- 
mer in the STIMER macro instruction. It 
first checks to determine if an existing 
element can be used. A usable element may 
be available if an STIMER macro instruction 
has been given for the same task in which 
the current STIMER macro instruction was 
encountered. This element could be an 
expired element, an element in the timer 
queue, or one that was changed to an inter- 
ruption request block by the Timer Second- 
Level Interruption Handler. The STIMER 
routine reuses expired elements and removes 
and reuses elements that are on the timer 
queue. If the existing element has been 
changed to an interruption request block 
that is being used, or if no usable element 
exists, the STIMER routine obtains space 
for and builds a new element. It places in 
the current TCB a pointer (TCBTME) to the 
timer queue element that it has created. 
The STIMER routine then uses the Timer 
Enqueue subroutine to position the com- 
pleted element on the timer queue. See the 
format of the timer queue element (TQE) in 
Section 12, "Control Blocks and Tables". 



TIMER INTERROPTION HANDLING 

When a time interval that was placed 
into the timer expires, an external inter- 
ruption occurs and control is automatically 
given to the External First-Level Interrup- 
tion Handler (see Figure 6-3) . 
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Figure 6-3. Timer Interruption Handling 



Basically, the External First Level 
Interruption Handler saves information 
about the interrupted program, distin- 
guishes between timer and other types of 
external interruptions, and, for timer- 
caused interruptions, gives control to the 
Timer Second-Level Interruption Handler. 

The Timer Second- Level Interruption 
Handler takes any actions the programmer 
specified (in the STIMER macro instruction) 
to be performed upon expiration, and places 
another interval into the timer. 

The module name of the Time Second-Level 
Interruption Handler depends on the options 
included at system generation. Figure 6-H 
indicates these module names. 

Determining What Actions Are To Be 
Performed in System/ 360 

When a timer interruption occurs, the 
topmost element in the timer queue repre- 
sents the expired interval. The Timer 
Second-Level Interruption Handler obtains 
the address of the topmost element from 
main storage location TQPTR, removes the 
element from the timer queue, and to deter- 
mine what action to take, examines bits 6 
and 7 of the first word in the element (see 
Figure 6-5). 

Note: When the time sharing option is 
included in the system and the expired TQE 
is for the time sharing driver, the Timer 
SLIH issues a TSEVENT macro instruction 
with the TSLICE parameter. If the expired 
TQE is for a time sharing user not in main 
storage, a TSEVENT macro instruction is 
issued with the USERRDY parameter to indie- 
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ate to the driver that the time sharing 
user is to be brought into main storage 
(swapped-in) . 

If the TASK or REAL parameter was given 
in the STIMER macro instruction, and if an 
asynchronous exit routine was specified in 
the STIMER macro instruction, the Timer 
Second-Level Interruption Handler (TSLIH) 
must make further tests to determine what 
action should be taken. If no entry to an 
asynchronous exit routine is desired, the 
queue element is given an expired status. 
If an exit is specified and the timer queue 
element (TQE) is TASK type, the TSLIH 
changes the TQE to an interruption request 
block (IRB) containing an interruption 
queue element (IQE), and gives control to 
the Stage 2 Exit Effector. If an exit is 
specified and the TQE is REAL, the TSLIH 
determines if the issuer of the STIMER was 
an initiator. If an initiator did not 
issue the STIMER macro instruction, the 
TSLIH proceeds as if an exit was specified 
and the TQE was TASK type. If an initiator 
did issue the STIMER macro instruction, 
further processing must be performed. 

If the TQE is REAL, if an exit is speci- 
fied, and if an initiator issued the STIMER 
macro instruction, it indicates that the 
30-minute wait limit (imposed by job-step 
timing) has expired. When this case 
occurs, the problem program must be abnorm- 
ally terminated while the timer queue ele- 
ment must be reinstated as TASK type with 
the actual CPU time remaining value. The 
Timer Second-Level Interruption Handler 
accomplishes this by branching to ABTERM 
with the address of the problem program 
job-step TCB (TCBLTC field of initiator 
TCB) to schedule the step for ABEND. The 
TSLIH also passes ABTERM a unique ABEND 
code (522) which indicates that the 30- 
minute wait limit expired. Upon return 
from ABTERM, the TSLIH marks the timer 
queue element as TASK type and off the 
queue, and moves the CPU time remaining 
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TASK parameter was used in 
STIMER macro instruction. 
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Figure 6-5. Actions Taken After Timer Expiration 



value from its save slot (TQESAV) to the 
time of expiration/time remaining slot 
(TQEVAL) within the TQE. 

If a WAIT parameter was given in the 
STIMER macro instruction, the Timer Second- 
Level Interruption Handler gives control to 
the Post routine, directing it to post an 
appropriate event control block (contained 
within the timer queue element) and thus 
signal expiration of the interval. 

After either of the above actions has 
been completed, the time of expiration 
(TOX) value of the topmost element is 
placed into the 6-hour pseudo clock. The 
TOX value minus the last value in the 6HPC 
is placed in the interval timer. (The ele- 
ment representing the recently expired 
interval has been removed from the queue. ) 

Determining What Actions Are To Be 
Performed in System/ 370 

When the element at the top of the timer 
queue is removed by the timer SLIH, the 
synchronization indicator is checked to 
determine if this element is the 24-hour 
element or represents a REAL or WAIT type 
request that requires special processing by 
the timer SLIH. This indicator will have 



been set by the STIMER routine when the 
original interval requested was greater 
than one hour. Interim processing by the 
timer SLIH may have cleared this indicator. 



If special processing is not required, 
System/360 processing continues. If the 
indicator is set, the timer SLIH subtracts 
the value in the TOD Clock from the value 
in the TQEWORK field. If the result is 
or negative, the interval being timed has 
elapsed and processing continues as in 
System/360. If the result is positive but 
less than one hour, the synchronization 
indicator is cleared, and the remaining 
interval is converted from 1.048576-second 
units to timer units and placed in the 
TQEVAL field. The timer enqueue routine is 
used to convert the timer units to time of 
expiration and to place the element on the 
timer queue. 



If the result of the calculation is 
positive and greater than one hour, the 
timer SLIH again sets the TQEVAL field to 
one hour, and uses the timer enqueue rou- 
tine to convert the timer units to a time 
of expiration, and to place the element on 
the timer queue. 
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Returning 6-Hour and Midnight Elements to 
the Queue in Systein/360 

When intervals represented by either the 
6-hour or niidnight supervisor queue ele- 
ments expire, the elements must be returned 
to the timer queue. Before it returns the 
6-hour supervisor element, the Timer 
Second-Level Interruption Handler subtracts 
6 hours from the times of expiration of all 
elements in the timer queue to reflect the 
passing of 6 hours since the elements were 
queued. It also adds 6 hours to the 24- 
hour pseudo clock unless its value is 18 
hours, in which case it resets the 24-hour 
pseudo clock to 0. The Timer Second-Level 
Interruption Handler then uses the Enqueue 
subroutine to position and queue the 6-hour 
element on the timer queue. 

Note ; When the time sharing option is 
included in the system and the midnight 
element expires, a TSEVENT macro instruc- 
tion is issued with the CHGTOD operand so 
that the time sharing driver updates the 
time of day in its internal control blocks. 

Before the Timer Second-Level Interrup- 
tion Handler returns the midnight element 
to the timer queue, it changes the date in 
the communications vector table. 

Returning 6-Hour and Midnight Elements to 
the Queue in Syst em/370 

This processing is identical with 
System/360 except that the 24-hour pseudo 
clock is not used in System/370. This is 
replaced by the MNIGHT field in module 
lEACVTPC which is used with the TOD Clock. 

SMF Processing 

When the System Management Facility 
(SMF) has been included in the system, the 
Timer SLIH may be required to perform addi- 
tional processing. 

If the timer interruption is recognized 
as following from the expiration of a 
supervisor 10-minute interval, the Timer 
SLIH obtains the accumulated system wait 
time for the 10 minutes from the second 
word of the save area SYSWSAVE. This value 
is added to the SMCAWAIT + 4 field in the 
system management control area. Each time 
that step termination is entered, this 
field is checked. If it is non-zero, a 
system 10-minute wait record is generated. 

The Timer SLIH then zeros the accumu- 
lated wait time field, places a value of 10 
minutes in the 10-minute TQE, and returns 
the TQE to the timer queue. 

If the timer interruption is recognized 
as a job, step, or wait time expiration, 
the Timer SLIH checks the timing control 



table (TCT) for the address of a user time 
limit expiration routine (lEFOTL) . If such 
a routine is present, and if the expired 
TQE belongs to the initiator, the Timer 
SLIH initializes an IRB/IQE representing 
the SMF Time/Output Limit Expiration rou- 
tine (lEATLEXT). The Stage 2 Exit Effector 
is then entered to schedule the execution 
of the SMF Time Limit Expiration routine. 



SMF TIME/OUTPUT LIMIT EXPIRATION ROUTINE 
(lEATLEXT) 

This routine, which is resident in the 
nucleus, provides an interface with a user 
time limit expiration routine (lEFOTL) . 

The routine receives control after a 
job-step, or wait time limit has expired 
(see above) . After setting the job or step 
nondispatchable, it passes control to the 
user time limit routine, indicating the 
type of expiration in Register 15. It also 
passes the address of a 72-byte register 
save area and the contents of the user data 
field (TCTUDATA) in the TCT. 

The user routine determines whether or 
not a time extension will be granted. It 
returns control to the SMF Time/Output 
Limit Expiration routine with a return code 
of for no time extension, 4 for time 
extension granted. If the return code is 
4, Register 1 contains the number of timer 
units to be granted. 

If an extension is granted, the SMF 
Time/Output Limit Expiration routine places 
the value of the extension into the expired 
TQE and places the TQE back on the timer 
queue. 

If no extension is to be granted, the 
action taken depends on the type of time 
limit that has expired: 

• If wait time expired, the problem pro- 
gram is abnormally terminated with an 
error code of 522. 

• If job-step time expired, the step is 
terminated. The SMF Wait Time Expira- 
tion routine converts the TQE into an 
IRB/IQE for standard linkage to the 
Stage 2 Exit Effector. 

Note: This routine (lEATLEXT) also handles 
output limit processing for SYSODT data 
set. See Section 11, "Special Features". 



TTIMER ROUTINE 

The TTIMER routine performs the two 
functions that can be requested with the 
TTIMER macro instruction. These are to 
provide the time remaining in a previously 
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requested time interval or to cancel a pre- 
viously requested interval. 



Determining Remaining Time in Svstein/360 

Before the TTIMER routine can determine 
remaining time, it must first locate the 
queue element that represents the affected 
interval. It obtains the address of the 
element from the TCB of the task being per- 
formed when the TTIMER macro instruction 
was given. If no element exists, or if the 
interval represented by the element has 
expired, this routine places time into 
general register 0. If an unexpired 
interval exists, the TTIMER routine deter- 
mines remaining time by using the following 
formula; 

Remaining Time = TOX - (SHPC - Timer) 

where; 

TOX = Time of expiration of the element. 
SHPC = Value in the 6-hour pseudo clock. 
Timer = Value in the interval timer. 

The interval may have expired while the 
TTIMER routine was being executed, in which 
case the above calculation would yield a 



negative remaining time value. If so, a 
value is returned in general register 0. 
If a positive remaining time value is 
obtained, it is placed unaltered (in timer 
units) into general register 0. 



Determining Remaining Time in Svstem/370 

When a TTIMER request specifies an ele- 
ment that has the synchronization indicator 
set, the TTIMER routine determines the 
remaining time by subtracting the value in 
the TOD Clock from the value in the TQEWORK 
field in the element. A or negative 
value indicates that the interval has 
elapsed, and TTIMER returns a in register 
0. A positive value is converted to timer 
units and returned to the requester in 
register 0. 

Canceling an Interval 

If the CANCEL option was used in the 
TTIMER macro instruction, the TTIMER rou- 
tine uses the Timer Dequeue subroutine to 
remove the corresponding element from the 
timer queue. The TTIMER routine also 
clears the TQE pointer (TCBTME) in the cur- 
rent TCB. The current task thus no longer 
has a timer queue element. 
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SUPPORTING CONSOLE COMMUNICATIONS 

The supervisor console support routines 
provide for input and output for one or 
more console devices. Input results from 
an unplanned interruption from an external 
device or from the main console; output 
results from the macro instructions WTO 
(Write to Operator) and WTOR (Write to 
Operator with Reply) . 

The operator causes an I/O interruption 
by pressing the REQUEST key on the 1052 
Printer-Keyboard, or the START key on a 
card reader. The I/O First-Level Interrup- 
tion Handler passes control to the I/O 
Supervisor, which determines that an opera- 
tor interruption service has been 
requested. Control then passes to the 
resident Attention routine. 

When the operator presses the INTERRUPT 
key on the operator control panel (OCP) , he 
causes an external interruption. In this 
case, control passes from the External 
First-Level Interruption Handler to the 
coiranunications task resident External 
Interruption Handler routine (lEEBClPE). 

The basic function of both the Attention 
routine and the External Interruption 
Handler routine is to. prepare for the per- 
formance of the communications task. This 
task is represented by a task control block 
(TCB) built into the nucleus at system 
generation. Routines operating under this 
TCB perform all input/output functions 
related to console communications. The 
communications task without Multiple Con- 
sole Support (MCS) is performed by three 
resident modules in the nucleus (Initiali- 
zation module lEECVINT, Unit Control Module 
lEECVUCM, and the Wait module lEECVCTW) by 
the nonresident Graphic Console Initializa- 
tion Module (lEECVGCI), and by the follow- 
ing nonresident SVC 72 modules: the Router 
(lEECVCTR) , the External Interruption 
Handler (lEECVCTX), and the device proces- 
sor modules with their associated open/ 
close modules. The Initialization module 
is linked to by the Master Scheduler and 
sets up control blocks when the nucleus is 
initialized. The unit control module (UCM) 
is set up by the Initialization routine, 
and is the primary control table for con- 
sole communications. The Wait module 
receives control when the communications 
task becomes active. 

The Wait module issues a WAIT macro 
instruction, specifying a list of event 
control block addresses (this list is 



called the event indication list) . The 
address of this list is contained in the 
UCM. When one of the event control blocks 
(ECBs) is posted, the communications task 
becomes a ready task. When it becomes the 
active task, the Wait module issues an SVC 
72 instjnaction. This SVC includes a common 
module, the Router module, and four seirvice 
modules. The processing services per- 
formed, in order of priority, are: extern- 
al interruption, attention, input/output 
completion, and WTO(R). 

The Router routine selects the service 
to be performed and passes control to one 
of four process modules. One of the pro- 
cess modules provides external interruption 
services. The other three provide console 
input/ output services: one handles input/ 
output for the 1052 Printer- Keyboard; the 
second handles input from unit record 
devices; and the third, output to unit 
record devices. Each of the three input/ 
output process modules is associated with 
an Open/Close support module, which pro- 
vides control blocks for Data Management 
and the I/O Supervisor. 

The flow of control following an exter- 
nal or input/output interruption from a 
console is shown in Figure 7-1. This 
figure also serves as a module directory 
for console input seirvices. 

Console output is initiated when a user 
or system program issues the WTO or WTOR 
macro instruction. Both macro instructions 
result in the performance of the transient 
SVC 35 routine. This routine adjusts the 
console queues and prepares for the perfor- 
mance of the communications task- 



There are two console queues, the buffer 
queue and the reply queue. The buffer 
queue points to messages that are to be 
written to the operator as a result of the 
WTO or WTOR macro instruction. The reply 
queue points to buffers for operator 
replies to the WTOR macro instruction. The 
SVC 35 service routine queues messages on 
the appropriate queue. 



The extent of both queues may be limited 
when the system is generated. An attempt 
to exceed the limit results in an ENQ macro 
instruction for the requesting task. Due 
to possible ENQ interlocks, and ENQ macro 
instruction is not issued for the Communi- 
cations Task, SYSLOG (in MCS) , a task in 
DAR, and SIRB, or any TCB that is higher 
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than the communications Task on the TCB 
ready queue. Instead, an additional buffer 
is obtained. The task receives control 
again when the number of elements in the 
queue falls below the limit. 

The flow of control for console support 
output is similar to that for input. The 
Router module has the additional responsi- 
bility of selecting an output device. The 
process modules issue the EXCP command for 
the 1052 Printer-Keyboard, or the WRITE 
macro instruction for a printer. For an 



operator reply (to the WTOR macro instruc- 
tion) , the I/O Completion Process module 
issues an SVC 34 instruction (Command Pro- 
cessing). The Command Processing service 
routine determines that the incoming com- 
mand is a response to the WTOR macro 
instruction, and passes control to the 
Reply Processor routine. 



Control flow for console support output 
is shown in Figure 7-2, which also serves 
as a routine directory. 
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Figure 7-1. Console Support: Input 



146 



Interruption Supervision 



sion 




1 Communication Task Resident 


^O or WTOR SVC 35 


. 


lEAQSCOO 






IGC0003E 




GC0103E 




lEAQNUOO 




lEENVWTO 




lEEVWTOR 




SVC FLIH 


Buffer Mgmt (Post 
Com Task ECB) 


Prepare for Reply 


































IGC0603E 








lEECVMLl 






MLWTO 
Load 1 








IGC0703E 








IEECVML2 






MLWTO 
Load 2 








IGC0803E 




lEAODS 




IEECVML4 




r n- .u ^ 


MLWTO 
Load 3 




I Dispatcher . 
















lEECVCTW 












lEECVCTB 





lEECUCM 






Wait Routine (Wait 
on ECBs in UCM) 


Unit Control 
Module 














|_ 




















Nonresident (SVC 72) 






lEECVCTR 






Router 






r 




















lEECVPM 




SVC 34 






Device 
Processor 


Command 
Processing 






1 






















lEECVOC 






Open/Close 
Support 

















Figure 7-2. Console Support: Output 
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REPLY prcx:essing 

The WTOR macro instruction causes a mes- 
sage to the operator to be written on a 
console device, and permits a reply from 
the operator to be returned to the request- 
ing routine. A WAIT macro instruction is 
also issued by the requester, specifying 
the ECB address contained in the WTOR macro 
instruction. When the operator enters his 
reply on a console device, the reply is 
placed in a buffer in the requester's 
region, and the specified ECB, also in the 
requester's region, is posted. 

An operator reply is processed by the 
communications task Reply Processor routine 
(IEE1203D). The routine is entered when a 
reply is received, or when the Rollin Reply 
Processing routine (RSTRQE) restarts 
replies that were deferred during rollout 
of a job step. (See "Freeing One or More 
Borrowed Regions Through Rollin" in Section 
5, "Main Storage Supervision.") 

The Reply Processor routine first edits 
the reply for proper format and length, 
then finds the reply queue element that 
represents the specified reply. Subsequent 
processing depends on whether the job step 
for which the reply was issued is currently 
rolled or swapped out. 



If the job step is currently rolled or 
swapped out (RQERO flag set) , the Reply 
Processor routine invokes the GETMAIN rou- 
tine to obtain IkH bytes from the system 
queue area. This space provides a tem- 
porary buffer in which the Reply Processor 
routine saves the reply until the job step 
is rolled in. The address of the temporary 
buffer, provided by the GETMAIN routine in 
register 1, is stored in the RQEXB field of 
the reply queue element. The Reply Proces- 
sor routine then moves the current reply to 
the temporary buffer. Since further reply 
processing is not possible while the job 
step is rolled out, the routine returns 
control to the highest priority ready task, 
via the Exit routine and the Dispatcher. 

If the job step is not currently rolled 
out (RQERO flag not set) , the Reply Proces- 
sor routine examines the RQEXB ("temporary 
buffer") pointer in the reply queue ele- 
ment. (In the program listing this pointer 
is called the "purging message address.") 
If the RQEXB pointer is zero, there is no 
temporary buffer. This means either that 
the reply was not received during a pre- 
vious period when the job step was rolled 
out, or that the job step was not rolled 
out. In this case, the routine moves the 
reply from the system buffer to the user's 
buffer. It then returns control to the 
routine's main line to complete the pro- 
cessing of the reply. If, however, the 



RQEXB pointer is not zero, there is a tem- 
porary buffer in which the routine placed a 
reply during a previous period when the job 
step was rolled out. In this case, the 
routine moves the reply from the temporary 
buffer to the user's buffer, then clears 
the pointer to the temporary buffer, and 
invokes the FREEMAIN routine to free the 
buffer's space. It then returns control to 
the routine's main line to complete the 
processing of the reply. 

The Reply Processor routine completes 
the processing of the reply by; 

• Removing the reply queue element from 
the reply queue and freeing its storage 
space. 

• Returning (queuing) the reply identifi- 
cation to the identification assignment 
pattern (UCMRPYI) in the unit control 
module. The reply identification is 
then available for reuse when a new 
WTOR macro instruction is issued. 

• Decreasing by one the RPQE count in the 
unit control module. This count indi- 
cates the number of reply buffers that 
are in use. 

• Invoking the Post routine to post the 
message-issuing routine's ECB. 

• Returning control to the highest 
priority ready task, via the Exit rou- 
tine and the Dispatcher. 

TSO Processing : When the time sharing 
option is included in the system, the Reply 
Processor routine determines from the RQET- 
JIDO and RQETJIDl fields if the user who 
issued the WTOR macro instruction is in 
main storage. If not, a TSEVENT macro 
instruction with the USERRDY operand is 
issued to inform the time sharing driver 
that this user is to be brought into main 
storage (swapped-in) . 



MULTIPLE-LINE WRITE TO OPERATOR ROUTINES 

Multiple-line Write to Operator (MLWTO) 
routines process multiple-line WTO requests 
by building write queue elements (WQEs) . 
When all write queue elements have been 
built, the WTO ECB in the UCM is posted and 
control is returned to the calling routine- 



Multiple-Line Write to Operator, Load 1 

Multiple-line Write to Operator, Load 1 
{IGC0603E) is entered from the Write-to- 
Operator routine (lEENVWTO) to process 
multiple-line WTO requests. IGC0603E 
builds the major WQE for the multiple-line 



its 



WTO. Upon initial entry, the routine 
determines if the entry has been made to 
add additional lines to an existing WTO. 
If so, the major WQE has already been 
built, and control passes to Load 2 
(IGC0703E). 

If IGC0603E is entered to build a major 
WQE, the first line passed is checked to 
ensure that it is within the user's 
storage. The number of lines passed is 
also resolved; this number determines the 
setting of the line number field in the 
WQE: 



Multiple-Line Write to Operator, Load 3 

Multiple-line Write to Operator, Load 3 
(IGC0803E) completes building the major 
WQE. Upon entry", IGC0803E stores the ^5LWTO 
identification number in the appropriate 
areas of the major WQE. If there are minor 
WQEs to be built, or if additional lines 
are to be added to an existing WTO requir- 
ing minor WQEs, control passes to Load 2 
(IGC0703E). Otherwise, the WTO ECB in the 
UCM is posted and exit is made to the cal- 
ling routine. 



Line number 
field in WQE 
1 

10 



Number of lines passed 

Zero or less 

Greater than 10 for a 
problem program 

Greater than 255 for a 
supervisor mode or 
protect key program 



If no error conditions are found, 
IGC0603E attempts to obtain buffer space 
for the major WQE. If space is not avail- 
able, and the routine issuing the MLWTO 
request is (1) the communications task, (2) 
the Damage Assessment routine (DAR), or (3) 
a system interruption request block (SIRB) , 
buffer space innmain storage is immediately 
obtained by the GETMAIN macro instruction. 
Otherwise, 1GC0603E issues an ENQ macro 
instruction and then a WAIT macro instruc- 
tion, specifying the WQE message buffer 
request ECB in the UCM. When a buffer 
becomes available, it is obtained by means 
of a GETMAIN macro instruction. 

When the buffer has been obtained, the 
text fields are filled in, and exit is made 
to Load 3 (IGC0803E) . 

Multiple-Line Write to Operator, Load 2 

Multiple-line Write to Operator, Load 2 
(IGC0703E) is entered to build minor WQEs. 
Upon entry, IGC0703E checks for available 
buffer space for the minor wqe. If none is 
available, and the routine issuing the 
MLWTO request is the communications task, 
DAR, or an SIRB, a GETMAIN macro instruc- 
tion is issued immediately for the required 
main storage. Otherwise, IGC0703E issues 
an ENQ macro instruction and a WAIT macro 
instruction, specifying the WQE buffer 
request ECB in the UCM. 

When a buffer is obtained, the text 
fields are filled in. If more lines remain 
to be written out, processing continues. 
When the end line is reached and all lines 
have been placed on the system output 
queue, IGC0703E posts the WTO ECB and exits 
to the calling routine. 



WRITE TO PROGRAMMER PROCESSING 

An extension of the WTO/WTOR function 
allows the system to communicate with the 
programmer instead of, or in addition to, 
the operator. When a WTO or WTOR macro 
instruction is coded with the ROnTCDE=ll 
parameter, the message is written to the 
system message class output data set. The 
message may also be written to the console, 
depending upon other conditions. For a 
detailed explanation, refer to the MVT Job 
Management PLM. 



SUPPORTING MULTIPLE CONSOLE COMMUNICATIONS 

The Multiple Console Support (MCS) rou- 
tines handle I/O for up to 32 system opera- 
tor consoles. Input results from an atten- 
tion (I/O interruption) from an active con- 
sole. Output results from a WTO(R) macro 
instruction being issued in a problem pro- 
gram or in a system task. MCS also handles 
external interruptions from the operator 
control panel, I/O complete conditions. 
Delete Operator Message (DOM) macro 
instructions, console switching, and system 
and console output queue management. 

As in systems without MCS, control is 
routed by the External First-Level Inter- 
ruption Handler for external interruptions, 
and by the I/O First-Level Interruption 
Handler for console device attentions and 
I/O complete interruptions (see Figure 
7-3). WTO(R) and DOM macro instructions 
are handled by SVC 35 and SVC 87 respec- 
tively. The routing results in the posting 
of one of the H ECBs (external, attention, 
WTO(R), DOM) in the Unit Control Module 
(UCM) , or the posting of one of the I/O 
ECBs pointed to by the event indication 
list (EIL) within the UCM. The communica- 
tions task TCB, created within the nucleus 
at system generation, is then indicated as 
ready. The dispatcher passes control to 
the communications task when its TCB is the 
highest priority TCB on the queue. 
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Figure 7-3. Communication Task with MCS 
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In addition to the ECBs and the pointer 
to the EIL, the UCM also contains pointers 
to the system output queue, the reply queue 
elements, and the UCM entries (see Figure 
7-4) . At system generation, a UCM entry is 
constructed for each console device speci- 
fied by the SCHEDULE and SECONSLE macro 
instructions (a composite console has 2 UCM 
entries) . Each UCM entry contains pointers 
to the processor module for that device, to 
the console output queue, and to the 
alternate console, and contains the routing 
codes and command authority codes assigned 
to the device. The console output queue is 
a series of pointers to selected WQEs on 
the system output queue. The first byte of 
each pointer contains indicators reflecting 
the status of the corresponding WQE in 
relation to the device. 

The communications task for MCS consists 
of 8 modules in the nucleus, the Console 
Switch, Mini-Router, and NIP Message Buffer 
Writer modules in the SVCLIB, and the 
Graphic Console Initialization module in 
the LINKLIB. These modules are: 

• Console Initialization Module (lEEC- 
VINT) , which is loaded by the Master 
Scheduler, initializes the console 
conf iguration- 



deletable from CRT (Cathode Ray Tube) 
consoles only. 



Mini-Router Module (lEECMCTR) , which 
passes control from the resident com- 
munications task module to the appro- 
priate nonresident communications task 
modules. 



• NIP Message Buffer Writer Module 

(lEECMWTL) , which writes messages from 
the buffer created by the Nucleus 
Initialization Program. 

• Attention Handler Module (lEECVCRA) , 
which receives control from the I/O 
Interrupt Handler to post the attention 
ECB. 

• External Interruption Handler 
(lEECVCRX) , which receives control from 
the External First-Level Interruption 
Handler to post the external ECB. 

The following paragraphs describe the 
executable communications task modules. 
Unless otherwise stated, all returns are to 
the calling routine or module. 



• Graphic Console Initialization Module 
(lEECVGCI), which initializes the dis- 
play console configuration. 

• Unit control Module (lEECVUCM) , which 
is a non- executable module containing 
pointers and indicators. This is the 
primary control table for console 
communications . 

• Router Module (lEECMQWR), which 
receives control when the communica- 
tions task is entered. It passes con- 
trol to the service modules for ECB 
postings and for queue management. 

• Console Switch Modules (lEECLCTX, 
lEECMCTX, lEECNCTX, lEECOCTX) , which 
switch consoles as a result of an ex- 
ternal interruption, an unrecoverable 
I/O error, or a VARY command. 

• Device Interface Module (lEECMDSV), 
which passes control to appropriate 
device support routines when there is 
I/O to be performed, or consolidates 
system and console output queues. 

• WTO(R) Service Module (lEECMWSV) , which 
queues WQEs to appropriate console out- 
put queues. 

• DOM Service Module (lEECMDOM), which 
marks specified operator messages as 



Console Initialization Module (lEECVINT) 

The Console Initialization module is 
loaded by the Master Scheduler to initia- 
lize the operator consoles. If the hard 
copy log is a console, the NIP Message 
Buffer ECB in the UCM is posted. If the 
hard copy log is SYSLOG, the ECB posting is 
bypassed, permitting the System Log Initia- 
lization routine to print the buffer. The 
Console Initialization module then searches 
the UCM, changing the UCB name of each 
device to an address and setting the open 
pending flag. If an address cannot be 
determined for a UCB name, a message is 
issued to the master console and the search 
continues with the next UCB name. The con- 
sole performing the IPL was assigned as the 
master console by NIP, and the Console 
Initialization routine only prepares secon- 
dary consoles. A message is written to 
each MCS console advising the operator of 
its unit address, its alternate's address, 
its console identification number, its dis- 
play area configuration, its command code 
and routing code authorization, its status 
(active or inactive), and whether it is the 
master console, a secondary console, or the 
hard copy log. If the system includes dis- 
play consoles, control passes to the Graph- 
ic Console Initialization Module (lEECVG- 
CI). Upon return frcan lEECVGCI, the Con- 
sole Initialization module returns control 
to the Master Scheduler IPL routine. 
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Figure 7-4. System and Console Output Queues 
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Graphic Console Initialization Module 
(lEECVGCI) 

The Graphic Console Initialization 
module is entered from the Console Initia- 
lization Module when that routine deter- 
mines that console initialization is 
required for one or more display consoles. 
lEECVGCI first searches for a UCM repre- 
senting a display console. If none are 
found, control is returned to the Console 
Initialization routine. If one is found, 
the routine issues a LOCATE macro instruc- 
tion to search for SYSl.DCMLIB. When SYSl. 
DCMLIB is found, the routine issues an OPEN 
macro to open SYSl.DCMLIB. If either the 
LOCATE or the OPEN fail, an error message 
is written to the operator's console, and 
one console in each transient group is made 
resident (the console whose TDCM was ini- 
tially placed in the transient area) . If 
SYSl.DCMLIB is successfully opened, lEECVG- 
CI attempts to read a copy of the PFK 
definitions for each console into main 
storage. If the read is unsuccessful, a 
message is issued to the operator. When 
all display consoles in the system have 
been initialized, control returns to the 
Console Initialization Module. 

Mini-Router Module (lEECMCTR) 



This module is entered as a result of an 
SVC 72 instruction issued by a resident 
communications task routine. An SVRB is 
created as a result of the SVC instruction 
for the execution of this module and the 
other nonresident communications task and 
device processor modules. lEECMCTR issues 
an XCTL macro instruction to pass control 
to the appropriate device processor module. 

Router Module (lEECMQWR) 

The Router module contains a WAIT macro 
instruction and a series of ECB and status 
tests in the following order: 

1. RMS Processing 

2. External Interruption 

3. Attention Interruption 

H. I/O Completion Interruption 

5. Output Processing 

6. WTO(R) Processing 

7. Queue Management 

8. DOM Processing 

9. NIP Message Buffer Writing 

When one of the ECBs specified by the 
WAIT macro instruction is posted, the com- 



munications task becomes a ready task. On 
becoming an active task, the Router module 
determines the service needed and passes 
control to the appropriate module to pro- 
cess the interruption. When control 
returns, the Router module retests all ECBs 
and status indicators that may have changed 
while the first interruption was being pro- 
cessed. To allow for the servicing of 
higher-level interruptions, output process- 
ing returns to the Router after each con- 
sole output queue is processed (see 
lEECMDSV below) . When no further process- 
ing can be done, the WAIT macro instruction 
is re-issued and control returns to the 
dispatcher. 



Console Switch Modules (lEECLCTX, lEECMCTX. 
lEECNCTX, lEECOCTX) 



These modules receive control from: 



• Router module to switch master consoles 
as a result of an external interrup- 
tion. 



• Device support routines to switch to 
the alternate console when there is an 
unrecoverable I/O error on a console. 



• SVC 3H to switch to the alternate of 
the master console as a result of a 
VARY MSTCONS command. 

• lEECMDSV to switch the hard copy func- 
tion from the SYSLOG to the master con- 
sole when SYSLOG is inoperative. 

lEEClCTX uses the parameter list passed 
by the calling routine to determine the 
type of function required (see Figure 7-5). 
If entered because of a VARY MSTCONS com- 
mand, lEECLCTX adds the routing and command 
codes of the master console to those of its 
alternate. lEECLCTX passes control to lEE- 
COCTX if the master console was the hard 
copy log and its alternate is a graphic 
console. Otherwise, control is passed to 
lEECMCTX to issue indicative messages. 

If lEECLCTX was entered because of hard 
copy failure on SYSLOG, control is passed 
to lEECOCTX. 

If lEECLCTX was entered because of an 
external interruption or for a failing con- 
sole, the routing and command codes of the 
master or failing console are added to 
those of its alternate. If the new console 
is a graphics console and the old console 
was also the hard copy log, control is 
passed to lEECOCTX. Otherwise, for a suc- 
cessful console switch, control is passed 
to lEECMCTX. 
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If the alternate of a failing console is 
a graphics console in output-only status, 
lEECLCTX may force a status switch so that 
the alternate can handle the functions of 
the failing console. 

If a primary console does not have an 
active alternate, the routing and command 
codes are added to those of the master con- 
sole. If the master console does not have 
an active alternate, a message is issued to 
all active consoles requesting a VARY 
,STCONS command from any console. If there 
are no active consoles and a console device 
is included that has an audible alarm, an 
OPEN macro instruction is issued for the 
device and the alarm is soimded three 
times. For all cases where a console 
switch cannot be successfully made, 
lEECLCTX returns control to the calling 
routine. 

lEECMCTX constructs two messages to ind- 
icate to the operator that a console switch 
has occurred and the attributes of the new 
console. lEECMWSV is used to queue the 
WQEs to the console output queue of the new 
console. lEECMCTX passes control to 
lEECNCTX to adjust the output queues of the 
new console. 

lEECNCTX places the WQEs that were on 
the output queue of the old console on the 
console output queue of the new console, 
deleting duplicate messages. If the WQE 
represents a system status display, the WQE 



is deleted. Multiple-line WTO messages, 
other than status displays, are passed to 
the new console if the end line of the mes- 
sage is on the old console's message queue 
at the time of the console switch. The 
close pending indicator is set and the 
device busy flag is set off in the UCM 
entry of the old console, and lEECNCTX 
returns control to the calling routine. 

lEECOCTX switches the hard copy log to 
the alternate of a new console when the new 
console is a graphic device and the old 
console was performing the hard copy func- 
tion. If the alternate console is also a 
graphics device, lEECOtTX searches all 
active consoles starting with the master 
console for an active, nongraphic device. 
If none is found, the master console is 
specified as the hard copy device. When 
the hard copy log has been assigned to a 
console, a message indicating this is 
placed on the console output queue of that 
console, the WQEs for the hard copy log are 
placed on the console output queue. lEE- 
COCTX passes control to lEECMCTX. If the 
WQE represents a system status display, the 
WQE is deleted. Multiple-line WTO mes- 
sages, other than status displays, are 
passed to the new console if the end line 
of the message is on the old condole' s mes- 
sage queue at the time of the console 
switch. 

lEECOCTX also switches the hard copy log 
from SYSLOG to the master console when 
there is a SYSLOG failure. If the master 
console is a graphic console, lEECOCTX 
searches for an active, nongraphic device 
as previously described, but does not 
requeue WQEs, and returns control to the 
calling routine instead of lEECMCTX. 

Device Interface Module (lEECMDSV) 

This module consists of 4 subroutines 
that control the interface with the device 
support processor routines and manage the 
output queues for the devices. It receives 
control from the Router module when an 
attention or I/O ECB has been posted, when 
it has been processing output and there is 
more output to process (see DEVSERVA) , or 
when an output queue needs consolidating. 
It also receives control from the WTO(R) 
processing routine lEECMWSV when there is 
output to be processed. 

DEVSERVB receives control when an atten- 
tion or I/O ECB has been posted. After 
satisfactorily testing console conditions, 
control is passed to DEVSERV to interface 
with the appropriate device support 
routine. 

DEVSERVA receives control when there is 
more output to be processed- When it is 
first entered, it searches from the first 
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UCM entry for a UCM entry of an active con- 
sole whose output queue can be processed. 
When it is subsequently entered from the 
Router, the search starts with the next 
entry after the last UCM entry processed. 
The search ends when an output queue is 
found that can be processed, or when the 
last UCM entry has been inspected. If an 
output queue is found, control is passed to 
DEVSERVA to interface with the appropriate 
device support routine. 

Note: Because one WQE may be placed on 
several device output queues, and because 
DEVSERVA handles only one UCM entry each 
time it is entered, DEVSERVA may be re- 
entered from the Router module to finish 
processing output queues. DEVSERVA must 
return to the Router after processing each 
output queue to allow for the servicing of 
the higher priority external, attention, 
and I/O ECBs which may have been posted 
while DEVSERVA was processing. 

DEVSERV is entered from DEVSERVA or 
DEVSERVB to branch to the appropriate 
device support routine. Upon return, if 
entries on the console output queue have 
been processed and marked as no longer 
needed, control is passed to the DEQ 
subroutine . 

DEQ receives control when DEVSERV or 
CLEANUP need console output queues ser- 
viced. DEQ inspects the console output 
queue for WQE pointers marked as no longer 
needed. Each WQE pointer so flagged is 
marked as a null entry and the use count of 
the WQE is decremented by one. If this 
decrementing results in the use count 
reaching zero (all specified consoles have 
received the message) , and DEQ determines 
that the message is to go to hard copy, 
control is passed to lEECMQCN (in lEECMWSV) 
to put the WQE pointer on the hard copy 
device's output queue, or a WTL is issued 
to SYSLCG. If the message is not to go to 
hard copy and there is no reply queue ele- 
ment associated with the WQE, the WQE is 
freed or marked as available. If a major 
WQE, representing a multiple-line WTO, is 
flagged as having one of its related minor 
WQEs with a use count of zero (which indi- 
cates that the minor WQE's message has been 
passed to all consoles) , the remainder of 
the WQE chain is searched, and the storage 
of any available minor WQEs is returned to 
the system. If a major WQE is flagged as 
no longer needed, the entire major/minor 
chain is returned to the system. Return is 
made when the last WQE pointer on the con- 
sole output queue has been examined. 

CLEANUP receives control when system 
output queues need consolidation. It 
examines each WQE on the system output 
queue and control is passed to DEQ for each 
WQE that has been serviced and is to be 



sent to hard copy. If it isn't to be sent 
to hard copy, DEQ frees the WQE. Control 
returns to CLEANUP to process all WQEs on 
the system output queue. 



WTO(R) Seiryice Module (lEECMWSV) 

This module gains control from the Rout- 
er when the WTO ECB is posted. WQEs that 
have been queued to the system output queue 
and have not been serviced by this routine 
are processed at this time. If a user exit 
routine is provided, a parameter list con- 
taining the text, routing codes, and 
descriptor codes is passed to it. If the 
routing codes have not been modified or 
suppressed, if the WQE is for a WTOR, or if 
there is no user exit routine, control is 
passed to the subroutine lEECMENQ which 
compares routine codes, IDs, and hardcopy 
requirements, and places the WQE on the 
appropriate console output queues. If the 
WQE represents a multiple-line WTO, the 
routine sets an output- pending flag in the 
console to which the request has been 
queued. When all WQEs have been examined, 
control passes to lEECMDSV (DEVSERVA) to 
initiate output queue processing. Upon 
return, control is returned to the Router. 

DOM Service Module (lEECMDOM) 

This module gains control from the Rout- 
er when the DOM ECB is posted (by the DOM 
macro instruction being issued in a problem 
program or system task) . It may also be 
entered directly from the system purge rou- 
tine (IEECMED2) at the end of a job step. 
When entered from the Router, message IDs 
in the DOM element list are compared with 
the WQEs on the system output queue. The 
matching WQEs are marked for deletion 
unless the WQE is to go only to hard copy. 
If a Model 85 Operator Console is active, 
control passes to the processor routine for 
that device for deleting messages from the 
console screen. Upon return, the DOM ele- 
ment list is freed by a FREEMAIN macro 
instruction and the DOM ECB is cleared. 

When entered from the system purge rou- 
tines, lEECMDOM compares WQEs with a pro- 
tect key. A request for purge of protec- 
tion key zero in ignored. Those that match 
are marked for deletion unless they are to 
go only to hard copy. If any graphic con- 
soles exist, the messages in each device's 
Display Control Module are similarly com- 
pared and marked for deletion. 

NIP Message Buffer Writer Module (lEECMWTL) 

This module issues an SVC 36 if the SYS- 
LOG has been specified as the hard copy log 
and has been initialized. Otherwise, an 
SVC 35 is issued to write the NIP messages 
to the operator. 
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REPLY PROCESSING 

MCS reply processing, a function of SVC 
34, differs from non-MCS reply processing 
in that when a WTOR is issued to more than 
one console, a reply is accepted from any 
console that received the WTOR. The first 
reply accepted is broadcast to all consoles 
that received the WTOR. 



CONSOLE SUPPORT 



buffer management. This function is 
performed by lEECMDSV and lEECMWSV. 



1052 Console Processor 2 (lEECMPMl) : 
Provides the processing necessary to 
present multiple-line WTO messages, 
including system status displays, on 
the 1052 operator console and printer 
consoles in systems with MCS . It also 
rings the audible alarm on the 1052 
when a permanent I/O error occurs. 



Console support is part of the Communi- 
cations Task. The following modifications 
are made to the Communications Task: 



1052 Open/Close routine (lEECVOCX) : 
Provides open and close functions for 
the console device. 



Pointer to the console support proces- 
sor is added to the UCM Entry for the 
2740 only. 

Pointer to the master DCM is added to 
the UCM Entry for every CRT console- 



UNIT CONTROL MODULE 

The Unit Control Module (UCM) is the 
primary control table for console communi- 
cation. It is a non-executable module con- 
taining ECBs used in the WAIT/POST 
mechanism in the Write-to-Operator and Con- 
sole Support routines. 



CONSOLE SUPPORT ROUTINES 

This section describes the logic flow of 
the support routines for the IBM 1052 
Printer-Keyboard, the IBM 1403, 1443, and 
3211 Printers, the IBM 2540 Card Read 
Punch, and the IBM 2740 Communications Ter- 
minal Model 1. The 1052, 1403/1443, and 
2540 may operate with or without Multiple 
Console Support (MCS) . Changes to module 
operation resulting from the inclusion of 
MCS are noted. The 2740 is available only 
in systems that include MCS (See Figure 
7-6). 

1052 Console Support Routines (MCS 
Optional) 

The console support routines for the IBM 
1052 Printer-Keyboard perform Read, Write, 
Open, and close functions, as well as buff- 
er management. 

• 1052 console Processor 1 (lEECVPMX) : 
Provides I/O buffer management and con- 
structs channel programs to perform 
read and write operations in systems 
without MCS . 

• 1052 console Processor 1 (lEECMPMX) : 
Contains MCS modifications to lEECVPMX 
processing. lEECMPMX does not perform 



Printer Device Support Routines 

The device support routines for printers 
are similar to those for the 1052 in that 
they provide Write, Open, and Close func- 
tions, and buffer management. 

• Printer Processor (lEECVPMP) : Provides 
I/O buffer management and issues a 
WRITE macro instruction to write to the 
printer. This routine operates in sys- 
tems without MCS . 

• Printer Processor (lEECMPMP) : Contains 
MCS modifications to lEECVPMP proces- 
sing. This routine does not perform 
buffer management. 

• 1052/Printer Processor 2 (lEECVPMl): 
Processes multiple-line WTOs for 1052 
Printer-Keyboards and printer consoles 
in systems without MCS . 

• Printer Open/Close routine (lEECVOCP): 
Provides open and close functions for 
the console device. 



Card Reader Device Support Routines 

The device support routines for the card 
reader are similar to those for the 1052 in 
that they provide Read, Open, and Close 
functions and buffer management. 

• Card Reader Processor (lEECVPMC) : Pro- 
vides I/O buffer management and issues 
a READ macro instruction to bring input 
from the card reader into a WQE in sys- 
tems without MCS . 

• card Reader Processor (lEECMPMC) : Con- 
tains MCS modifications to lEECVPMC 
processing. This module does not per- 
form buffer management. 

• Card Reader Open/Close Module (lEEC- 
VOCC) : Provides open and close func- 
tions for the console device. 
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Figure 7-6. 1052 and 2740 Console Support Routines with MCS 



2740 Console Support Routines (MCS Only) 

The 2740 Processor routine (IEEC2740) is 
created at System Generation by the macro 
SGIHBOOO. It performs OPEN and CLOSE func- 
tions. The READ and WRITE functions are 
performed by the following unchanged BTAM 
modules : 

• IGG019MA, BTAM Read/Write routine 

• IGG019MB, BTAM Channel End and Abnormal 
End appendages 

• IGG019M0, BTAM Device I/O module (table 
used by IGG019MA) 

OPEN is performed when the open pending 
flag in the Unit Control Module (UCM) entry 



is on and the UCM entry is not already 
open. A LOAD is issued to obtain the 
addresses of the BTAM modules. The address 
of the 2740 ECB is placed in the UCM entry 
and Event Indication List. The DEB is 
initialized from the Communication Task 
TCB, and placed at the head of the TCB DEB 
queue. The Appendage Vector Table is 
initialized, and the line to the 2740 is 
initialized via the LOPEN macro instruc- 
tion. The open flag of the DCB and UCM 
entry is turned on, and the open pending 
flag is turned off. 

CLOSE is performed when the close pend- 
ing flag in the UCM entry is on, the output 
queue is empty, and the console is not 
busy. The address of the ECB in the event 
indication list is replaced with the 
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address of the UCM entry. The address of 
the ECB in the UCM entry is zeroed. The 
DEB is removed from the TCB DEB queue. The 
UCB is set to indicate that it can be allo- 
cated. A DELETE macro instruction is 
issued on the BTAM modules. The active 
flags in the DCM entry and the control 
blocks are set to indicate that the device 
is closed. 

READ is performed when the 2740 is not 
busy and a message has been sent to the 
terminal, or a READ I/O complete has been 
successfully processed and the output queue 
is empty- The BTAM module, IGG019MA is 
given control to perform this function, 
and, if the READ is successful, the busy 
flag is set in the UCM entry. 

WRITE is performed when the output pend- 
ing flag in the UCM entry is set, the 2740 
is not busy, and the output queue is not 
empty. WQE pointers on the console output 
queue are examined. When a WQE is found 
that can be written, control is passed to 
the BTAM module, IGG019MA. If the WRITE is 
successful, the busy flag is set in the UCM 
entry. 

I/O complete conditions cause the busy 
flag in the UCM entry to be turned off. If 
the complete is for a successful READ, the 
message text is translated from 2740 code 
to EBCDIC and searched for backspace and 
cancel codes . If the message is to be 
ignored, control is passed to the BTAM 
module, IGG019MA for another READ opera- 
tion. If the message is to be accepted, as 
SVC 34 is issued so the Command Processor 
routines of the Master Scheduler can pro- 
cess the REPLY command. Upon return from 
the Master Scheduler, the processor 
attempts to perform output if the 2740 is 
not busy and there is output on the console 
output queue. If the 2740 is busy, control 
is returned to the Communications Task 
module (lEECMDSV) . If the I/O complete 
condition is for a successful WRITE, the 
WQE pointer on the console output queue is 
marked as no longer needed, and control is 
returned to lEECMDSV. 

If a condition code of is returned by 
a BTAM module, the 2740 processor retries 
the I/O operation, or passes control to the 
Console Switch routine (lEECMCSW) in the 
Communications Task. 



DEVICE INDEPENDENT DISPLAY OPERATOR CONSOLE 
SUPPORT (DIDOCS) ROUTINES (OPTIONAL) 

Device Independent Display Operator Con- 
sole Support (DIDOCS) support, also 
referred to in this publication as Display 
Console Support, provides uniform operator 
console support for the following display 
console devices: 



• 2250 Display Unit, Models 1 or 3 

• 2260 Display Station, Model 1 with 2848 
Display Control, Model 3 

• Model 85 CRT Display (Feature 5450) 

• Model 165 Display Console 

• Model 91 Display Console 

• Model 195* Display Console 

Note: The Model 91 and Model 195 Display 
Consoles are functionally equivalent to 
2250 Display unit. Model 1. 

The Display Console Support takes advan- 
tage of device-dependent features of each 
display device (such as the use of the 
light pen on the 2250 for message dele- 
tion) . This section describes the logic 
flow of the Display Console support rou- 
tines (See Figure 7-7) . 

The Display Console Support routines 
receive control from MCS when one of the 
following events occurs for a display 
console: 

• An attention caused by the operator 

• Console switching 

• I/O completion 

• A WTO, WTOR, or command 

• A Delete Operator Messages (DOM) 
request 

• A Timer Interruption 

• Status Display on the Queue 

The following routines comprise the Dis- 
play Console Support: 

• DIDOCS Processor Routines (IGC5107B, 
IGC5Z07B, IGC6107B, and IGC6Z07B) — 
provide an interface between Display 
Console Support and MCS. The Processor 
routines receive control from MCS when 
an operator or system request is 
entered that requires processing by the 
DIDOCS routines. If the console 
involved in the request has a transient 
DCM, Processor 0, Load 1 (IGC6107B) 
receives control. Processor 0, Loads 1 
and 2, (IGC6107B, IGC6207B) provide 
transient DCM swapping support and per- 
manent program function keyboard (PFK) 
update support, cind then pass control 
to Processor 1, Load 1 (IGC5107B) for 



♦The Model 195 applies to both System/360 
and System/370 models. 
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continued processing. Processor 1, 
Load 1 receives control either from 
Processor 0, or directly from MCS (when 
the request involves a console that has 
a resident DCM) . Processor 1, Loads 1 
and 2 (IGC5107B, IGC5Z07B) route con- 
trol to other display console routines 
as required to process the request. 



Open/Close routine {IGC5G07B) - opens 
and closes display console device. 



2250 I/O 1 and 2 routines (IGC5P07B, 
IGC5Q07B) - handle input/output opera- 
tions for the 2250 Display Unit. 



2260 I/O 1 and 2 routines (IGC5R07B, 
IGC6R07B) - handle input/output opera- 
tions for the 2260 Display Station. 

Model 85 I/O routine (IGC5H07B) - 
handles input/output operations for the 
Model 85 CRT Display used as an opera- 
tor console. 
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Figure 7-7. CRT Console Support (High Level) 
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• Asynchronous Error routine (IGC5C07B) - 
initializes DCM on an OPEN; blanks the 
screen and displays an appropriate 
error message for the operator. If a 
permanent error occurs, it passes con- 
trol to MCS for console switching. 

• Message 1, 2 and 3 routines (IGC5D07B, 
IGC5E07B, IGC6D07B) - contain all mes- 
sages used for Display Console Support. 

• Display 1, 2 and 3 routines (IGC5207B, 
IGC5307B, IGC6207B) - write all mes- 
sages from the Operating System to the 
operator except those to be deleted and 
status display messages and mark mes- 
sages according to their descriptor 
codes. 

• Roll Mode routine (IGC5J07B) - removes 
messages from the screen at interval 
specified by the operator. 

• command routine (IGC5407B) - analyzes 
type of command in entry area and takes 
appropriate action, or passes control 
to another Display Console Support rou- 
tine for action. 

• Options routine (IGC5A07B) - analyzes 
CONTROL command entries specifying the 
S operand to determine their legitima- 
cy. If legitimate, this routine 
changes the screen options as requested 
by the operator and routes control to 
another Display Console Support routine 
as required. 

• Delete 1, 2, 3, and H routines 
(IGC5607B, IGC5707B, IGC5807B, 
IGC5907B) - erase answered WTOR mes- 
sages from the screen as well as mes- 
sages specified for deletion by the 
operator (CONTROL command, light pen, 
and cursor) , or by the system (DOM 
macro instruction) . 

• Light Pen-Cursor Service routine 
(IGC5F07B) - analyzes the type of func- 
tion indicated by light pen or cursor 
operations and routes control to the 
appropriate Display Console Support 
routine. 

• PFK 1 and 2 routines (IGC6A07B, 
IGC6B07B) - analyze and enter commands 
requested by the depression of a PFK 
key or by light pen selection of a dis- 
played PFK key number. These routines 
also process requests to define or 
redefine the commands associated with 
PFK keys. 

• Multiple-Line Write to Operator rou- 
tines (IGC0603E, IGC0703E, IGC0803E, 
IGC0903E) - process multiple-line WTO 
requests by building the necessary 
write queue element (WQE), and chaining 



the MLWTO requests to the system output 
queue. 

• Status Display Interface routines 
(IGC6L07B, IGC6M07B, IGC6N07B, IGC- 
6O07B, IGC6P07B, IGC6Q07B, IGC6T07B) - 
process inline and out-of-line MLWTOs, 
and handle control of out-of-line 
displays. 

• Cleanup routine (IGC6G07B) - removes 
status displays from the message 
queues, and reinitializes the Screen 
Area Control Blocks (SACBs) . 

• Timer Interpreter routine (IGC5K07B) - 
analyzes timer intervals and passes 
indicators to the Processor routine to 
notify it as to vSiich, if any, of the 
display consoles are ready to be 
rolled, assuming roll mode has been 
specified for one or more consoles. 

The following control blocks (including 
content description) are used by Display 
Console Support routines: 

• Communication Task Extended Save Area 
(CXSA) - transfer control block with 
the address of the UCM entry. MCS 
places the address of this control 
block into Register 1 when it passes 
control to the Display Console Support 
routines . 

• UCM entry - control area in Dnit Con- 
trol Module (UCM) with the addresses of 
a block of WQE pointers, UCB, DCM, and 
I/O Blocks. The UCM entry provides 
access to all information required by a 
display. 

• Write Queue Element (WQE) - messages on 
the output queue to be written. 

• Unit Control Block (UCB) - attention 
information. 

• Display Control Module (DCM) - console 
screen and support interface 
information. 

• I/O Blocks - status of device. 

• Storage Utilization Block (SUB) — con- 
trol information used by DIDOCS, RMS 
channel programs, and (if transient 
DCMs or PFK definitions are included in 
the system, direct access I/O informa- 
tion. There is only one SUB in the 
system. 

Each unit DCM is divided into two sec- 
tions: a resident section and a section 
that may or may not be resident, at the 
user's option. The resident portion of the 
DCM (the RDCM) contains screen control 
information and the address of the main 
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storage area assigned to the optionally 
transient portion of the DCM (the TDCM) . 
(If the optionally transient portion of the 
DCM is actually transient, the main storage 
area addressed by the RDCM may be used by 
the transient DCMs of several consoles.) 



The RDCM may also contain one or more 
screen area control blocks (SACBs) , which 
contain information about each status dis- 
play area defined for the console's screen. 



The optionally transient portion of the 
DCM (the TDCM) contains two sections: the 
device independent section and the device 
dependent section. The device independent 
section contains: 



• DOM addresses 

• CCW area 

• Input area 

• Delete request buffer 

• Processor name 

• Option values 

• Communication bits 

• Field sizes for dependent section 

The dependent section includes the 
fields shown in Figure 7-8: 



IField I 2260^1 22602| 22501 M85| 

(Buffer Address I I I I I 

I Table I I I 101 8 1 

I CCW Area | 80 | 80 | 112 j 72] 

(Screen Image Buffer j 960 j 960 | 3866 | 2800 j 

I COM ID Numbers | 44 | 44 | 188 j 120 j 

I SCREEN control | | ill 

I Table I 22 I 22 j 94 j 60 | 

[Secondary Screen j j III 

I Control Table | 11 j 11 | 47 | 301 

I ^ i nput- output I 

I 2 output- only j 

L J 

Figure 7-8. Variable Sized Fields of the 
TDCM 



Display Console Support Routine 
Descriptions 

This section contains a description of 
each of the Display Console Support rou- 
tines. These descriptions provide a gener- 
al explanation of each routine. 



DIDOCS Processor Routines 

The DIDOCS Processor routines (IGC5107B, 
IGC5Z07B, IGC6107B, and IGC6Z07B) receive 
control from MCS when any of the following 
operator or system requests is entered that 
requires processing by the DIDOCS routines: 

• Open/Close request 

• Attention 

• Enter (command input) 

• Cancel 

• Light Pen (message deletion) 

• PFK or Light Pen (command input) 

• I/O Complete 

• DOM request 

• Hard copy went down 

• Hard copy cetme back up 

• Messages to be displayed 

• Timer interruption 

• Roll needed 

DIDOCS Processor , Load 1 

Processor 0, Load 1 (IGC6107B) , receives 
control from Processor 1, Load 1 (IGC5107B) 
to begin processing of a request involving 
a display console with a transient DCM. 
The Processor Load 1 routine queues the 
request and then determines if the tran- 
sient portion of the DCM (the TDCM) is 
required to process the request. If the 
transient DCM is required and is not alrea- 
dy in main storage, this routine brings it 
into main storage. Control then passes to 
the Processor 1, Load 1 routine to continue 
processing of the request. 

Processor 0, Load 1, also checks for a 
request for a permanent PFK update. Per- 
manent copies of PFK definitions are main- 
tained on SYSl.DCMLIB; the operator may 
make permanent changes to the definitions. 
If a request for a permanent change to a 
PFK definition is encountered. Processor 0, 
Load 1, builds the appropriate channel pro- 
gram and issues an EXCP macro instruction 
to accomplish the change. When I/O is com- 
plete for a PFK update. Processor 0, Load 
1, passes control to Processor 0, Load 2 
(IGC6Z07B), to check for successful I/O. 

When Processor 0, Load 1 is entered 
because an I/O operation is complete, con- 
trol passes to Processor 0, Load 2, to 
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determine if an I/O error occurred or if 
additional I/O processing is required. 

When Processor 0, Load 1, is entered 
from Processor 0, Load 2, (indicating that 
I/O is satisfactorily completed) , control 
passes to Processor 1 Load 1. 



DIDOCS Processor 0, Load 2 

Processor 0, Load 2 (IGC6Z07B), receives 
control from Processor 0, Load 1, 
(1GC6107B) when I/O processing is complete. 
Load 2 determines if any additional I/O 
processing is required and if any I/O 
errors occurred. Action is taken as 
follows: 

• I/O Error — Writes an error message to 
the operator's console and passes con- 
trol back to MCS with an indication 
that console switch is required. 

• Additional I/O Necessary — Updates and 
executes the channel program. 

• I/O Complete — passes control back to 
Processor 0, Load 1. 

DIDOCS Processor 1, Load 1 

Processor 1, Load 1 (IGC5107B), receives 
control to begin processing of an operator 
or system request (as listed above) - Con- 
trol is received either directly from MCS 
(when the console involved in the request 
does not have a transient DCM) , or from the 
Processor 0, Load 1 routine (when the con- 
sole has a transient DCM that has been 
brought into main storage) . 

The Processor 1 routine determines the 
reason for entry and passes control to the 
appropriate Display Console Support rou- 
tine. Figure 7-9 summarizes the reasons 
for entry to the DIDOCS Processor routine, 
the resulting exit, and the reasons for 
exit. 

DIDOCS Processor 1, Load 2 

DIDOCS Processor 1, Load 2 (IGC5Z07B) 
receives control from Processor 1, Load 1 
(IGC5107B) for processing of close 
requests, and for continued processing of 
request parameter lists. 

If entry has been made for processing of 
a close request. Processor 1, Load 2, 
determines whether or not the screen has 
been erased. If it has not been erased, 
flags are set in the DCM and control is 
passed to the device dependent I/O routine 
to erase the screen. If the screen has 
been erased, control passes to the Open/ 
Close routine (IGC5G07B) to complete pro- 
cessing of the close request. 



If entry is made for processing of a 
request parameter list, the type of request 
is determined and control is passed to the 
appropriate Display Console Support rou- 
tine. This process is a continuation of 
the request-handling process begun in Pro- 
cessor 1, Load 1. If the request in the 
parameter list has already been processed, 
control is returned to Processor 1, Load 1. 

Open/Close Routine 

The Open/Close routine {IGC5G07B) opens 
and closes the DCB for the display console 
devices. It decides whether to open or 
close a device by checking a parameter 
passed to it in the communication task 
extended save area (CXSA) . It may be 
entered to open with a special exit to the 
MCS Console Switch routine (lEECLCTX) to 
sound the alarm three times indicating that 
no console is available. 

After a successful open, control returns 
to either the Processor 1, Load 1 routine 
(IGC5107B), if a console exists, or the MCS 
External Interruption routine, if the no 
console condition is met. Following a suc- 
cessful close, control returns to the MCS 
Console Switch routine (lEECLCTX) via a 
branch on register 14. 

2250 I/O 1 Routine 

2250 I/O 1 routine (IGC5P07B) performs 
requested 2250 input/output (I/O) opera- 
tions in proper screen format. It checks 
the communication bytes in the DCM (I/O 
communication bytes 1, 2, and 3 and message 
communication byte 1) against pre- 
established bit settings to determine the 
type and format of I/O requested. 

Each I/O request is checked in this 
manner and, if applicable, the appropriate 
CCWs are built until all the I/O requests 
are set up in the channel program. This 
routine builds CCWs for the following I/O 
requests: 

• Perform Read Manual Input (RMI) 

• READ entry area 

• WRITE message area 

• WRITE instruction line 

• WRITE entry area 

• WRITE warning line 

• Insert cursor 

This routine also blanks the instruction 
line, entry area, and warning line as 
requested prior to performing I/O in these 
areas . 
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Figure 7-9. 



DIDOCS Processor Routine Entries 



If a light pen interruption occurs, con- 
trol passes to the Light Pen/Cursor Service 
routine (IGC5F07B) . If one of the follow- 
ing I/O operations is requested, control 
passes to the 2250 I/O 2 routine (IGC5Q07B): 

• WRITE asynchronous error message 

• WRITE message; message waiting 



• WRITE status display 

• Erase screen 

• Sound alarm 

For all other cases, control passes to the 
Processor 1, Load 1 routine (IGC5107B) . 
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2250 I/O 2 Routine 

2250 I/O 2 Routine (IGC5Q07B) performs 
its input/ output operations in an identical 
manner to that of 2250 I/O 1 routine 
whenever it is called by the latter to pro- 
cess one or more of the following I/O 
requests via the building of CCWs: 

• WRITE asynchronous error message 

• WRITE message waiting message 

• WRITE status display 

• Erase screen 

• Sound alarm 

This routine also picks up the channel pro- 
gram address from DCMDSAV. The only exit 
from this routine, however, is to Processor 
1, Load 1 (IGC5107B) . 



2260 I/O 1 Routine 

The 2260 I/O 1 routine (IGC5R07B) per- 
forms 2260 input/output (I/O) operations in 
proper screen format. The module first 
tests for a status switch request. If this 
request is present, exit is made to the 
2260 I/O 2 routine (IGC6R07B) . It checks 
bits set in the DCM to determine which I/O 
operation is to be performed. One of three 
possible I/O operations may be requested; 
(1) perform Read Manual Input (RMI) in 
order to find cursor (2) WRITE screen, or 
(3) READ entry area. This routine normally 
exits to the Processor 1 , Load 1 routine 
(IGC5107B) unless the cursor is determined 
to be located adjacent to the Start of Mes- 
sage (SOM) symbol and the screen is in 
"hold" mode. In the latter case, the CAN- 
CEL function is to be performed and the 
2260 I/O 1 routine exits to the Command 
routine (IGC5t07B). If the cursor is 
located other than in the entry area, the 
line and character posititioning is com- 
puted and exit is to the Light Pen/Cursor 
Service routine (IGC5F07B). 



2260 I/O 2 Routine 

The 2260 I/O 2 routine (IGC6R07B) is 
entered from the 2260 I/O 1 routine 
(IGC5R07B) when a change in a 2260 conso- 
le's operating mode is requested by the 
operator or required by the system. 
IGC6R07B is called twice during each con- 
sole switch. On the first pass, the rou- 
tine determines the new console operating 
mode (full-capability or output-only) and 
passes control to the Cleanup routine 
(IGC6G07B) to continue processing of the 
console mode switch. 



When IGC6R07B receives control for the 
second time during a console switch, the 
routine determines if "message stream" mode 
has been requested. If so, the routine 
sets a "roll delete" mode indicator in the 
DCM (this places the console in "roll- 
deletable" mode for message deletion) and 
exits to the Timer Interpreter routine 
(IGC5K07B) to continue processing of the 
console mode switch. If message stream 
mode was not requested, control is returned 
to the 2260 I/O 1 routine (IGC5R07B) to 
complete processing of the console mode 
switch request. 



Model 85 I/O Routine 

The Model 85 I/O routine (IGC5H07B) per- 
forms Model 85 input/output (I/O) opera- 
tions in proper screen format. It checks 
the communication bytes in the DCM (I/O 
communication bytes 1, 2, and 3 and message 
communication byte 1) against pre- 
established bit settings to determine the 
type and format of I/O requested. The 
module first tests for a status switch 
request. If this request is present, exit 
is made immediately to the Cleanup routine 
(IGC6G07B). 



Each I/O request is checked in this 
manner, and, if applicable, the appropriate 
CCWs are built until all the I/O requests 
are set up in the channel program. This 
routine builds CCWs for the following I/O 
requests: 



Read Manual Input (RMI) 

READ entry area 

WRITE message area 

WRITE asynchronous error message 

WRITE message waiting message 

WRITE status display 

WRITE instruction line 

WRITE entry area 

WRITE warning line 

Insert cursor 

Blank warning line 

Blank instruction line 

Blank entry area 

Erase screen 

Sound alarm 
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Control returns to the Processor 1, Load 1 
routine (IGC5107B) . 

Asynchronous Error Routine 

The Asynchronous Error routine 
{IGC5C07B) handles asynchronous errors and 
reopen conditions. In the case of per- 
manent synchronous or asynchronous errors, 
this routine perforins console switching by 
exiting to the MCS routine. Console Switch, 
Load 1 (lEECLCTX). 

When a asynchronous error occurs, the 
Asynchronous Error routine sets indicators 
in the DCM to erase the screen and display 
an appropriate error message. These indi- 
cators are set for Message 2 CIGC5E07B) 
which moves the appropriate error message 
into the DCM, and the appropriate device 
I/O routine which erases the screen and 
writes the error message. Control passes 
to Message 2. 

When a reopen condition is met, this 
routine initializes the DCM and passes con- 
trol to the appropriate device I/O routine 
to write the screen. 

Message 1 Routine 

The Message 1 routine (IGC5D07B) con- 
tains messages used by Display Console Sup- 
port. It tests bit settings in the DCM to 
determine which message to move into the 
screen image buffer while distinguishing 
between error and warning messages. This 
routine then sets indicators in the DCM to 
write the screen. Message 1 sets the sound 
alarm bit unless an "Unviewable Message" or 
"Deletion Requested" warning message is 
written. If the bit settings in the DCM 
indicate that a message is to be written, 
the Message routine moves the message into 
the DCM and exits to the appropriate device 
I/O routine. Otherwise, control passes to 
the Processor 1, Load 1 routine (IGC5107B). 

Message 2 Routine 

The Message 2 routine (IGC5E07B) con- 
tains the asynchronous error and deletion 
request error messages used by the Display 
Console Support- It tests bit settings in 
the DCM to determine which messages to move 
into the screen image buffer. This routine 
then sets indicators in the DCM to write 
the screen, sets the sound alarm bit, and 
exits to the appropriate device I/O 
routine. 

Message 3 Routine 

The Message 3 routine (IGC6D07B) con- 
tains the PFK support error messages used 
by Display Console Support. It tests bit 
settings in the DCM to determine which mes- 
sages to move into the screen image buffer 



(in the DCM) . The routine then sets indi- 
cators in the DCM to write the screen, sets 
the sound alarm bit, and exits to the 
appropriate device I/O routine. 



Display 1 Routine 

The Display 1 routine CIGC5207B) dis- 
plays all Operating System messages except 
those to be deleted (unless DEL=N) and sta- 
tus display messages. It searches the out- 
put queue for write queue elements (WQEs) 
to be displayed. If this search is suc- 
cessful, control is passed to Display 3 
(IGC6207B) which places the message (s) into 
the next available line in the screen image 
buffer of the DCM and marks the message (s) 
according to its descriptor code as pro- 
vided by MCS. 

If a status display is overlaying mes- 
sages on the screen. Display 1 exits to 
either Delete 2 (IGC5707B), in case an 
intervention required action message (s) is 
on the screen, or Delete 4 (IGC5907B) , if 
there are no action messages and automatic 
deletion is specified and not yet tried. 
If automatic deletion is not specified or 
has been tried, this routine exits to eith- 
er Message 1 (IGC5D07B) to display an 
"Unviewable Message" message, or the appro- 
priate device I/O routine to display a 
"Message Waiting" message. If roll mode is 
specified. Display 1 exits to Display 2 
{IGC5307B) to set the timer as required. 
If a message is greater in length than the 
maximum text for a line in the screen image 
buffer, or an accepted reply is on the 
screen. Display 1 exits to Display 2. When 
no messages are added to the DCM, Display 1 
returns control to MCS via a branch on 
register l**. 



Display 2 Routine 

The Display 2 routine (IGC5307B) checks 
bit settings in the DCM to determine wheth- 
er the splitting of messages or the marking 
or replies is to be performed. It then 
either splits messages greater in length 
than 72 characters (70 for the 2250), or 
marks all accepted replies and associated 
WTORs as automatically deletable in the 
screen image buffer. In the latter case. 
Display 2 sets the timer as required. If 
splitting is performed. Display 2 exits to 
Display 1 (IGC5207B). It exits to whichev- 
er of the following routines is appropri- 
ate, if marking accepted replies is 
performed: 

• Delete 2 routine (IGC5707B) - to delete 
intervention required action messages 

• Delete 4 routine (IGC5907B) - to per- 
form automatic deletion 
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• Device-dependent I/O routine - to per- 
form input/output CI/O) 



• Message 1 routine (IGC5D07B) 
"Dnviewable Message" warning 



to write 



• Processor 1, Load 1 (IGC5107B) - to 
continue processing 

Display 3 Routine 

The Display 3 routine (IGC6207B) 
receives control initially from Display 1 
(IGC5207B) to dequeue, mark, and move mes- 
sages into the message area of the display 
control module (DCM) from the console out- 
put queue. 

Display 3 searches the console output 
queue for messages to be displayed. When 
one is found. Display 3 takes the following 
action according to the message type: 

• In-line multiple-line WTOs - control 
passes to Status Display Interface 1 
(IGC6L07B) to process these messages. 
Upon return from Status Display Inter- 
face 1, processing continues if other 
messages are on the queue. Otherwise, 
control passes to Display 2 (IGC5307B) 
to continue processing. 

• Out-of-line multiple- line WTOs - these 
messages are not processed by this rou- 
tine; if encountered the routine 
ignores them. Out-of-line multiple- 
line WTOs will eventually be processed 
by the Status Display Interface rou- 
tines which receive control from the 
Processor routines. 

• Single-line WTOs and WTORs - Display 3 
places the message in the first avail- 
able line in the screen image buffer 
(in the DCM) , and marks the message 
according to the descriptor code pro- 
vided by MCS. 

After Display 3 has processed all mes- 
sages in the queue, control passes to Dis- 
play 2 for processing of split messages and 
for marking of replies. 

Roll Mode Routine 

The Roll Mode routine (IGC5J07B) per- 
forms the roll function when messages are 
on the WQE and the time specified for roll 
is satisfied. When messages on a display 
console are ready to be rolled, the routine 
rolls the messages in the screen image 
buffer. If the CONTROL command operand DEL 
is set to roll deletable (RD) mode, the 
specified number of deletable messages are 
removed. If DEL is set to roll (R) mode, 
the specified number of messages, including 
action messages, are removed. It also 
stores the information for inserting the 



number of message lines remaining on the 
output queue into the first two character 
positions of the first new message to be 
displayed following a roll. Control passes 
to the Timer Interpreter {IGC5K07B) unless 
DEL=RD and no deletable messages are on the 
visible portion of the screen, in which 
case control passes to the appropriate 
device I/O routine to write the message 
waiting message. 

The RNUM value specified in the CONTROL 
S command determines the number of lines 
the Roll Mode routine removes, unless one 
of the following exceptions exists: 

• Fewer lines on the output queue than 
RNUM value (less lines rolled) 

• Number of lines displaced by a status 
display is smaller than RNUM value 
(less lines rolled) 

• Roll Deletable (RD) mode specified and 
number of deletable lines on screen is 
smaller than RNUM value (less lines 
rolled) 

• Top line on screen following roll is 
continuation line (one more line 
rolled) 

Command Routine 

The Command routine (IGC5H07B) analyzes 
the commands in the entry area, processes 
CANCEL attentions, and processes requests 
to remove message numbers. According to 
the reason for entry, the routine takes the 
following action: 

• CANCEL attention: the Command routine 
sets flags, alters the DCM as appropri- 
ate, and then passes control to the 
appropriate I/O routine. 

• CONTROL command (with no other 
operands) : the Command routine passes 
control to the Delete 3 routine 
(IGC5807B) to erase a segment of mes- 
sages from the screen. 

• Delete verification: the Command rou- 
tine passes control to the Delete H 
routine (IGC5907B) to process the dele- 
tion verification. 

• CONTROL commands: the Command routine 
issues an SVC 34 to pass the command to 
the system's command processing rou- 
tines. When control returns, the Com- 
mand routine determines if a parameter 
list was provided by the SVC 34 rou- 
tines. If not, the Command routine 
blanks the entry area and passes con- 
trol to the appropriate I/O routine. 

If a parameter list was provided, and 
the command in the entry area was CON- 
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TROL £,N, -the Command routine erases 
the message numbers from the screen and 
passes control to the appropriate I/O 
routine. For all other commands, the 
Command routine passes control to the 
routine indicated in the SVC 34 para- 
meter list. 

• All other commands: the Command rou- 
tine issues ain SVC 35 to write the com- 
mand to the message area of the console 
screen; it then issues an SVC 34 to 
pass the command to the system's com- 
mand processing routines. When control 
returns from the SVC 34 routines, the 
Command routine determines if a para- 
meter list was provided. If not, the 
Command routine blanks the entry area 
and passes control to the appropriate 
I/O routine. If a parameter list was 
provided, the Command routine passes 
control to the routine indicated in the 
parameter list. 

Options Routine 

The Options routine (IGC5A07B) receives 
control from the Command routine to analyze 
the minor operand values (DEL, CON, SEG, 
RNUM, RTME) of the CONTROL command specifi- 
cation (S) operand and to determine their 
legitimacy. If these minor operands and 
their respective values are legitimate, the 
Options routine changes the current values 
accordingly and indicates the screen 
options currently in effect. If these 
minor operands and/or their values are not 
legitimate, this routine exits to the 
appropriate device I/O routine with 
instructions to write the appropriate mes- 
sage from the Message routine. The Options 
routine also displays all the current 
screen option values when requested by the 
CONTROL S [ , REF] command . 

• CON=N and no hard copy 

• DEIi=R or RD and no hard copy 

• DEIi=R or RD and no timer 

If a warning message is required, this rou- 
tine sets the appropriate indicators and 
continues processing. If, however, an 
error message is required, the Options rou- 
tine exits to Message 1 (IGC5D07B). 



Upon preparing to exit, the Options rou- 
tine indicates the proper location of the 
cursor. If a warning message is to be dis- 
played, this routine transfers control to 
Message 1. If the value of DEL is changed 
to or from R or RD, or if the RTME operand 
has been changed, the Options routine sets 
an indicator bit in the DCM and exits to 
the Timer Interpreter routine (IGC5K07B) . 
If a warning or error message is required. 



and a return to the Timer Interpreter rou- 
tine is also indicated, the Options routine 
exits to the Timer Interpreter with 
instructions to pass control to Message 1 
when finished. 

Delete 1 Routine 

The Delete 1 routine (IGC5607B) handles 
the erase commands, CONTROL E,F and CONTROL 
E,nn[,nn]. If conversational mode is in 
effect. Delete 1 updates the screen image 
buffer by marking and numbering those mes- 
sages selected for deletion, and passes 
control to Message 1 (IGC5D07B) to write 
the "Deletion Requested" message. If non- 
conversational mode is in effect. Delete 1 
updates the screen image buffer by marking 
and numbering those messages to be deleted, 
and passes control to Delete 4 (IGC5907B) 
for immediate deletion. Delete 1 exits to 
Message 2 (IGC5E07B) if the erase command 
is inconsistent, or if it has an invalid 
operand. 

Delete 2 Routine 

The Delete 2 routine (IGC5707B) handles 
the deletion of intervention required 
action messages and messages indicated for 
deletion by the DOM macro instruction. 
Delete 2 marks as automatically deletable 
those messages successfully acted upon or 
indicated for deletion by the DOM macro 
instruction, provided the display device is 
not busy or a delete request is pending. 
If the device is busy or a delete request 
is pending. Delete 2 passes control to the 
MCS Router routine (lEECMQWR). Delete 2 
marks all intervention required action mes- 
sages as automatically deletable and passes 
control to the Processor 1, Load 1 routine 
(IGC5107B) if a delete request is pending. 
Otherwise, Delete 2 passes control to eith- 
er Delete 4 (IGC5907B) if automatic dele- 
tion is desired, or to the appropriate 
device I/O routine to write the message 
area when automatic message deletion is not 
specified. 

Delete 3 Routine 

The Delete 3 routine (IGC5807B) handles 
the erase command, CONTROL [E,SEG] , and 
deletion by cursor or light pen. It 
updates the screen image buffer by marking 
and numbering the message area segment for 
deletion. If conversational mode is in 
effect. Delete 3 passes control to Message 
1 {IGC5D07B) to write the appropriate mes- 
sage on the instruction line requesting 
operator verification of the messages 
marked for deletion. If nonconversational 
mode is in effect. Delete 3 passes control 
to Delete 4 (IGC5907B) for immediate dele- 
tion. If the value of SEG is equal to 
zero, or if there are no deletable messages 
within the message area segment. Delete 3 
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exits to Message 2 (IGC5E07B) to display 
the appropriate error iressage. 

Delete 4 Routine 

The Delete 4 routine (IGC5907B) examines 
the message indicators in the screen con- 
trol table in the DCM and blanks those 
lines in the screen image buffer marked for 
automatic or regular deletion while it 
moves non-deletable lines up to the first 
available message line. This routine also 
handles the command, CONTROL D,N[,HOLD] by 
numbering all visible message lines. 

If T:he deletion of messages is success- 
ful when a status display is not on the 
screen and a full screen condition exists. 
Delete 4 returns control to Display 1 
(IGC5207B). Otherwise, Delete 4 exits to 
either Message 1 (1GC5D07B) to display a 
warning message informing the operator that 
unviewable messages are on the output queue 
if the screen is not yet full, or to the 
appropriate device I/O routine to display 
the "Message Waiting" warning message and 
write the entire screen. 

Light Pen/Cursor Service Routine 

The Light Pen/Cursor Service routine 
(IGC5F07B) handles light pen and cursor 
interruptions. If a light pen or cursor 
delete request occurs on the message line 
of a non-action message or on the asterisk 
of an action message, the routine transfers 
control to Delete H (IGC5907B) or Delete 3 
{IGC5807B) depending on whether delete 
verification is or is not indicated. If a 
light pen detect or cursor placement is on 
♦ENTER* in the instruction line, this rou- 
tine passes control to the appropriate 
device I/O routine to perform a READ opera- 
tion. When the light pen or cursor is 
positioned on *CANCEL* in the instruction 
line (to cancel a request) or on *E* in the 
status display title line (to erase a sta- 
tus display) , the Light Pen/Cursor Service 
routine passes control to the Command rou- 
tine (IGC5407B). When the light pen or 
cursor is positioned on *D C,K* in the 
instruction line or *F* in the status dis- 
play title line, control passes to the Com- 
mand routine. If the light pen is posi- 
tioned on a key number in the PFK display 
line, control is passed to the PFK 1 rou- 
tine {IGC6A07B). If the light pen or cur- 
sor is positioned on any other location 
than mentioned above, it is considered an 
error. Control passes to Message 1 
(IGC5D07B) or Message 2 (IGC5E07B) to dis- 
play the appropriate error message. 

PFK 1 Routine 

The PFK 1 routine (IGC6A07B) receives 
control from Processor 1, Load 1 (IGC5107B) 
when a PFK is pressed, or when a PFK key is 



to be verified or redefined. It also 
receives control from the Light Pen/Cursor 
routine (IGC5F07B) when a light pen inter- 
ruption occurs for a number displayed in 
the PFK display line. 

Upon entry, this routine determines the 
reason for entry. If entry has been made 
to cancel a PFK request, the commands asso- 
ciated with the canceled PFK key are 
removed from the entry area of the DCM. 
Also, control information is removed from 
the PFK area of the DCM so that later use 
of the same PFK key will cause new copies 
of the definitions to be used. If entry 
has been made to enter a command, the numb- 
er of the key is placed in the DCMPFKNM 
field of the DCM, and the routine checks to 
see that the key is valid. If it is not, 
exit is made to Message 1 (IGC5D07B) so 
that an error message can be issued. 
Otherwise, a check is made to see if the 
key is already in process. A key may have 
several commands associated with it, each 
of which must be processed separately. If 
the key is not in process, it is flagged as 
in process now, and a check is 'made to see 
if the key is defined as a list of key num- 
bers. If it is, control returns to the 
entry point of the routine so that each key 
number in the list can be processed 
separately. 

When the routine determines that a key 
number is associated with a command to be 
processed, the command is moved to the 
entry area buffer in the DCM. If the key 
is in conversational mode, the command is 
written to the screen where the operator 
may cancel or enter it. If the key is not 
in conversational mode, the command is 
executed by simulating an operator ENTER 
action. 

After all commands have been processed, 
the PFK work area is cleaned up and control 
is returned to the Processor 1, Load 1 
routine. 



PFK 2 Routine 

The PFK 2 routine (IGC6B07B) receives 
control from the Processor 1 Load 1 
(IGC5107B) routine when entry is made to 
redefine a PFK or to write or erase the PFK 
display line (the line of the display con- 
sole screen containing PFK key numbers 
which may be entered by light selection) . 

The routine first determines which func- 
tion was requested. If the request is to 
erase or display the PFK display line, exit 
is to the I/O routine for the device for 
which the display is requested. If the re- 
quest is to redefine a PFK, the routine 
scans the new command and, if no errors are 
encountered, replaces the old definition 
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with the new. Control is then returned to 
the Processor 1, Load 1 routine. 



Multiple-Line Write to Operator Routines 
(MCS) 

Multiple-line Write to Operator (MLWTO) 
routines process multiple-line WTO requests 
in systems with multiple console support 
(MCS) . 

Multiple-Line Write to Operator, Load 1 

Multiple-line Write to Operator, Load 1 
(IGC0603E) is entered when the Write-to- 
Operator routine (lEEMVWTO) determines that 
a multiple- line WTO request has been 
entered. IGC0603E builds a major WQE for a 
MLWTO request. 

Upon entry, IGC0603E checks if a major 
WQE already exists for the request. If so, 
the request is to build a minor WQE, and 
control passes to Load 2 (IGC0703E) to con- 
nect minor WQEs to the existing major WQE. 

If the request is to build a major WQE, 
IGC0603E attempts to obtain WQE buffer 
space in main storage for the major WQE. 
If space is not available, and the MLWTO 
request is from the communications task, 
DAR, or an SIRS, an ENQ macro instruction 
and a WAIT macro instruction are issued 
upon the WQE ECB. When buffer space has 
been obtained, the text fields are filled 
in. Control then passes to Load 2. 

Multiple-Line Write to Operator, Load 2 

Multiple- line Write to Operator, Load 2 
(IGC0703E) completes processing of the 
major WQE and begins processing of the 
minor WQEs. If entry is to complete a 
major WQE, the MCS and hard copy fields of 
the major WQE are filled in. If no minor 
WQEs are to be chained to the itajor WQE, 
control is passed to Load 3 (IGC0803E) to 
chain the major wqe to the system output 
queue. 

If entry is made to connect minor WQEs 
to a major WQE, or if, upon completion of a 
major WQE, minor WQEs are ready to be con- 
nected to it, buffer space for the minor 
WQEs is obtained in the same way as for a 
major WQE. On subsequent entries to build 
minor WQEs, a check is made to determine if 
any minor WQEs previously connected to the 
major WQE have become available for re-use 
by having been written to all the consoles 
required by their routing indicators. If 
so, the buffer space obtained earlier is 
re-used for another minor WQE. 

As each minor WQE is completed, control 
passes to Load 3 to chain the MLWTO request 
to the system output queue. 



Multiple-Line Write to Operator, Load 3 

Multiple-line Write to Operator, Load 3 
(IGC0803E) is entered to chain MLWTO 
requests to the system output queue. If a 
major WQE is to be chained, the MLWTO iden- 
tification number is placed in the appro- 
priate areas of the major WQE. 



If entry is to chain minor WQEs to the 
major WQE, the minor WQEs are chained and 
appropriate use count information is moved 
into them from the major WQE. When there 
are additional minor WQEs to be processed, 
control is returned to Load 2 (IGC0703E). 
Otherwise, control passes to Load 4 
(IGC0903E). 



Multiple- Line Write to Operator, Load 4 

Multiple- line Write to Operator, Load 4 
(IGC0903E) receives control from Load 3 
(IGC0803E). IGC0903E dequeues the WQE from 
the WTO resource if necessary. It then 
sets the appropriate return code in regist- 
er 15 and returns control to the routine 
that issued the MLWTO request. 



Status Display Interface 1 Routine 

The Status Display Interface 1 routine 
(IGC6L07B) receives control from the Pro- 
cessor 1, Load 1 routine (IGC5107B) or Dis- 
play 3 {IGC6207B) to process multiple- line 
WTO messages that do not have descriptor 
codes 8 and 9. Descriptor codes 8 and 9 
indicate that a display is a response to an 
operator's request and is to be presented 
out-of-line, in a display area of a display 
console. 



Upon initial entry, IGC6L07B sets a flag 
in the UCM indicating that a status display 
is in progress. This flag insures that all 
of the lines of the status display will be 
displayed contiguously to prevent inter- 
leaving of other messages with the lines of 
the status display. The routine then moves 
lines of the WTO into the DCM until a suf- 
ficient number of lines have been passed to 
fill the screen or until the last line is 
encountered. If the screen becomes full 
before the last line is encountered, exit ' 
is made to the device dependent I/O routine 
to issue a MESSAGE WAITING message. When 
the last line is passed to the DCM, the WQE 
turns off the multiple-line WTO flag in the 
UCM and checks the WQE buffer for addition- 
al messages to be processed. If any are 
found, control passes to the Display 1 rou- 
tine (IGC5207B) for further processing. 
Otherwise, control is passed to the I/O 
routine to display the messages that were 
moved to the DCM. 
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status Display Interface 2 Routine 

The Status Display Interface 2 routine 
{IGC6M07B) receives control from the Pro- 
cessor 1, Load 1 routine (IGC5107B) to pro- 
cess requests for multiple- line WTO mes- 
sages that have descriptor codes 8 and 9. 
These codes indicate that the message is a 
status display requested by the operator, 
and that the display is to be presented 
out-of-line in a display area on a display 
console screen. 

Opon initial entry, IGC6M07B searches 
the console output queue for a WQE repre- 
senting a multiple-line WTO. When one is 
found, the routine locates in the DCM the 
screen area control block (SACB) for the 
display area in which the display appears. 
If the WQE represents a new display, the 
SACB is initialized, and any status display 
in the area is dequeued. If the display 
area is now empty (that is, it contains no 
other operator messages), control passes to 
the Status Display Interface 6 routine 
(IGC6Q07B), which puts the message into the 
screen image buffer (in the DCM) three 
lines at a time. If the display will over- 
lay other operator messages, control passes 
to Status Display Interface t, {IGC6O07B) 
which sets up a write- area. This separate 
write-area will be used by the I/O routines 
to write the display to the screen. (This 
avoids using the DCM screen image buffer as 
a write-area, which would destroy the over- 
laid operator messages) . If message area 
lines below the display area in use require 
blanking, control passes to the Status Dis- 
play Interface 7 routine (IGC6T07B) . If 
the display area lines contain non- status 
display messages, a three line write-area 
is constructed. The status display is then 
written to the display area from the write- 
area by the device dependent I/O routine, 
leaving the messages in the DCM buffer 
intact. 

Status Display Interface 3 Routine 

The Status Display Interface 3 routine 
(IGC6N07B) receives control from the Pro- 
cessor 1, Load 1 routine (IGC5107B) to pro- 
cess CONTROL commands affecting out-of-line 
status displays (K D,H; K D,U; K D,F). 

If entry has been made for processing 
CONTROL commands, IGC6N07B takes action 
according to the operands of the command: 

• K D,H — an internal PM A is issued to 
stop the time interval updating of the 
display. The display remains in the 
screen but the routine rewrites the 
control line to contain frame and upd- 
ate options. 

• K D,U. — an internal MN A is issued to 
continue updating the display. The 



control line is rewritten to contain 
stop and hold options. 

• K D,f: — a control line containing the 
new frame number is built in the write- 
area and control passes to the I/O rou- 
tine to write the new frame. 

Status Display Interface U Routine 

The Status Display Interface 4 routine 
(IGC6O07B) receives control from the Status 
Display Interface 2 routine (IGC6M07B) to 
move lines of a status display from the WQE 
into a temporary write-area in the DCM. 
This routine is entered only for status 
displays that overlay other operator mes- 
sages on a display console screen. 

IGC6O07B uses the instruction line and 
the two lines of the entry area as the tem- 
porary write-area. It moves three lines of 
the message into this temporary write-area, 
and then exits to the I/O routine to write 
the lines to the screen. When the last 
line of the display is put into the tem- 
porary work area, the routine blanks any 
remaining display area lines and puts the 
FRAME LAST indicator in the control line. 

Status Display Interface 5 Routine 

The status Display Interface 5 routine 
(IGC6P07B) is entered from the Processor 1, 
Load 1 routine (IGC5107B) to process CON- 
TROL commands affecting out-of-line status 
displays (K E,D; PM A). 

Upon entry, IGC6P07B determines which 
command has been entered, and action is 
taken as follows: 

• K e,d: — the appropriate major and 
minor WQEs are removed from the queue, 
and control is passed by means of the 
XCTL macro instruction to the I/O rou- 
tine, which erases the display from the 
screen. 

• PM A — the dynamic display indicator 
in the DCM is turned off, the appropri- 
ate WQEs are removed from the queue, 
and control passes to the I/O routine, 
which erases the display from the 
screen. 

IGC6P07B also receives control from Sta- 
tus Display Interface 2 (IGC6M07B) when 
blanking of lines below a display area is 
required. Control passes to Status Display 
Interface 7 {IGC6T07B) to perform the 
required blanking. 

Status Display Interface 6 Routine 

The Status Display Interface 6 routine 
(IGC6Q07B) is entered from the Status Dis- 
play Interface 2 routine (IGC6M07B) to move 
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lines of a status display from the WQE into 
the appropriate message area lines of the 
screen image buffer (in the DCM) - This 
routine is entered only if the status dis- 
play does not overlay any other operator 
messages . 

Upon entry, IGC6Q07B moves lines from 
the WQE into the screen image buffer until 
the display area is filled. When all lines 
of the display have been moved, any lines 
remaining in the display area are blanked, 
and the control line is rewritten to indic- 
ate FRAME LAST. 



Status Display Interface 7 Routine 

The Status Display Interface 7 routine 
(IGC6T07B) receives control from Status 
Display Interface 5 {IGC6P07B) to blank 
message area lines below a status display 
that is being displayed in a display area. 

Upon entry, IGC6T07B determines the 
number of lines that require blanking and 
locates the first line to be blanked. It 
then fills the instruction line and the 
entry area (in the DCM) with blanks. After 
these lines are blanked, control passes to 
the device dependent I/O routine to blank 
the first three lines that require blank- 
ing. The I/O routine uses the three lines 
as a write-area to write blanks to the 
screen. This procedure prevents the mes- 
sage area from being broken up into blocks 
of general message traffic and blocks of 
status displays. It also allows any mes- 
sages that were overlayed with blanks to 
remain untouched in the DCM screen image 
buffer. When the status display is erased, 
the screen is again written from the screen 
image buffer, and the messages reappear. 

Cleanup Routine 

The Cleanup routine (IGC6G07B) receives 
control from the Open/Close routine when a 
request for closing a device has been 
entered; it also receives control from the 
Asynchronous Error routine when a request 
to vary console status has been entered or 
when a device is recovering from an asynch- 
ronous error. This routine removes status 
displays from the message queues, and rein- 
itializes the Screen Area Control Blocks 
(SACBs) . 

Upon entry, IGC6G07B determines the 
reason for entry and then determines if the 
console involved in the entry has a MONITOR 
Active display in "update" mode. If so, 
the display is stopped (STOPMN) . The rou- 
tine then searches the consoles SACBs for 
partially output status displays. If any 
are found, they are freed. The Cleanup 
routine then takes the following action 
according to the reason for entry: 



• CLOSE — the SACB configuration is 
reinitialized to the value specified 
during system generation, all messages 
are removed from the queue, and control 
passes to Processor 1 Load 1 
(IGC5107B) . 

• Change in status to SD — inline mes- 
sages are freed, the SACBs are rein- 
itialized to the values specified dur- 
ing system generation, and control 
passes to the Asynchronous Error rou- 
tine (IGC5C07B). 

• Change in status to MS — the SACB con- 
figuration is reinitialized to the 
values specified during system genera- 
tion, all SACBs are marked as unused, 
and control passes to the Asynchronous 
Error routine. 

• Change in status to FC — the SACB con- 
figuration is reinitialized to the 
values specified during system genera- 
tion, and control passes to the Asynch- 
ronous Error routine. 

• Asynchronous Error recovery — out-of- 
line displays in progress and on the 
output queue are freed, the SACB confi- 
guration is retained, and control 
passes to the Asynchronous Error 
routine. 

Timer Interpreter Routine 

The Timer Interpreter routine (IGC5K07B) 
analyzes the timer intervals at which each 
of the display console devices specifying 
roll mode is scheduled to be rolled, and 
sets indicators to notify the Roll Mode 
routine (IGC5J07B) whenever the timer 
interval has elapsed for one or more of the 
display console devices. 

The routine initially stores the timer 
interval (RTME if roll mode is specified, 
zero if not) for each display console 
device in its respective DCM. The greatest 
common divisor (GCD) of all the non-zero 
timer inteirvals is constantly updated as 
new devices are added as display consoles. 
The Timer Interpreter routine sets the 
timer equal to the GCD. 

Whenever the timer elapses, this routine 
adds the GCD to the time counter of each of 
the display console devices whose timer 
interval is not equal to zero. If the new 
total equals or exceeds the timer interval 
for one or more display console devices, 
the Timer Interpreter routine notifies the 
Processor 1, Load 1 routine (IGC5107B) that 
the messages on each of these devices are 
ready to be rolled. 

The Timer Interpreter gets control for 
one of three reasons. First, if control is 
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passed from the Processor routine, the 
timer has elapsed, in which case it returns 
to the Processor 1, Load 1 routine - 
Secondly, if the routine gets control from 
the Options routine, the Open-Close rou- 
tine, or the Asynchronous Error routine, 
the GCD needs to be updated for a new set 
of intervals. Control is passed from the 
Options routine when a display device is 
put into or taken out of roll mode, or the 
value of RTME is changed, in which case an 
exit is taken to the appropriate device I/O 
routine or one of the message routines. 
Entry is from the Open/Close routine when a 
display device in roll mode is removed as 
an operator's console and control returns 
to the Open/Close routine (IGC5G07B) . 
Entry is from the Asynchronous Error rou- 
tine to set a single timer interval of 30 
seconds for the removal of the error mes- 
sage and an exit is taken to Message 2 
{IGC5E07B). Thirdly, the routine gets con- 
trol from the Roll Mode routine to insert 
in the first two character positions of the 
first new message the number of message 
lines remaining on the output queue. The 
Timer Interpreter then exits to the appro- 
priate device I/O routine if the warning 
message bit is on. Otherwise, the Timer 
Interpreter passes control to the Display 1 
routine (IGC5207B) . 



SOPPORTING THE SYSTEM LOG 

The system log, an optional feature for 
systems with MVT or Model 65 multiprocess- 
ing, consists of two data sets cataloged at 
system generation on which critical system 
information is recorded. The existence of 
two data sets allows one (the primary data 
set) to receive data from the system, pro- 
blem programs and/or operators, while the 
other (the alternate data set) is being 
written to an output device. 

The log is initialized by lEEVLINl (see 
Figure 7-10) , which locates the log data 
sets and establishes the Log Control Area 
and log buffers, and lEEVLINOl, which 
writes the log JFCBs to the job queue, 
creates log DCBs, attaches the Log Writer 
routine (lEELWAIT) , and posts the log ECB. 
If the log data sets are not located by 
lEEVLINl, the operator is notified that the 
log option is not supported, consequently, 
WTL macro instructions are re-issued as WTO 
macro instructions to the primary/master 
console. LOG and WRITELOG operator com- 
mands are treated as NOPs by the control 
program and a message is sent to the issu- 
ing console informing the operator that the 
system log is not supported. If log 
initialization is unsuccessful, lEEVLINl 
returns control to lEEVWAIT (or to the Sys- 
tem Management Facility initialization rou- 
tine if that feature is included in the 
system) . 



Users communicate with the log through 
the WTL macro instruction and the operator 
commands LOG and WRITELOG. The WTL rou- 
tines (SVC 36) schedtile the entering of 
information into the system log. The LOG 
command is used to enter information into 
the system log from an operator's console. 
The WRITELOG command is used to request 
that the currently recording log data set 
be closed and queued to a SYSOUT writer of 
a particular class. If no class name is 
specified with the WRITELOG command, the 
data set will be scheduled for queueing to 
a SYSODT writer of the class specified at 
system generation. When the system log is 
performing the functions of the hard copy 
log (a log function of the multiple console 
support option), WTO and WTOR messages, as 
well as operator and system commands and 
their responses, may be entered on the sys- 
tem log by converting them to a WTL macro 
instruction. WTO and WTOR conversion is 
done in the MCS communications task module 
lEECMDSV. Conversion of the LOG command is 
done in the Command Scheduler (SVC 3t) 
routines . 

The log support routines function under 
their own TCB in a manner similar to the 
Communications Task routines. The module 
lEELWAIT is attached as part of the initia- 
lization process and issues a WAIT macro 
instruction specifying the log ECB. Upon 
initial entry to lEELWAIT, SVC 36 is issued 
to open the log data sets. 

Subsequent entries to lEELWAIT are 
caused when the log ECB is posted. The 
events which cause the log ECB to be posted 
are: 

• A WRITELOG t CLOSE} command has been 
issued or HALT processing has occurred. 

• The log buffer is full. 

If lEELWAIT is entered because a WRITE- 
LOG command was issued, an SVC 36 is issued 
to cause data set switching. The recording 
data set (primary) is closed and the other 
data set (alternate) is opened for input. 

If lEELWAIT determines that the log 
buffer is full, it ensures that the size of 
the log buffer to be written does not 
exceed the amount of space specified in the 
data extent block (DEB) . If the log buffer 
is equal to or less than the space remain- 
ing on the data set, the buffer ECB is 
posted, the log buffer is written to the 
data set, and a WAIT is again issued on the 
log ECB. Had the space remaining on the 
data set been insufficient, an SVC 36 would 
have been issued to simulate a WRITELOG 
command. 

When a WRITELOG CLOSE command is 
entered, the process of writing the remain- 
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ing text in the log buffer to the data set 
is the same as mentioned above for a full 
buffer condition. Then the currently re- 
cording data set is closed and the log 
function is deleted from the system. 

An SVC 3H must be issued to process the 
LOG and WRITELOG commands. The SVC 34 
module IEE1603D issues a WTL macro instruc- 
tion. For the WRITELOG command, IEE1603D 
posts the log ECB and the WRITELOG indica- 
tor is set in the Log Control Area. 

The WTL macro instruction results in an 
SVC 36. The module IEE0303F moves the mes- 
sage into the log buffer. If an additional 
message would overflow the buffer, the log 
ECB is posted, the buffer ECB is cleared, 
and control returns to the Master Schedul- 
er. When lEELWAIT receives control, it 
switches buffer pointers, thereby indicat- 
ing that the other (alternate) buffer is 
available for input. It then posts the 
buffer ECB, and proceeds to write the full 
buffer (primary) onto the data set. Since 
the buffer ECB has been posted, IEE0303F 
can now move a new message into the alter- 
nate buffer. When IEE0303F is entered from 
lEELWAIT because a WRITELOG was issued (SVC 
36 is issued in lEELWAIT) , control is 
passed directly to the second load of SVC 
36 IEE0403F. 

When IEE0403F is entered initially, the 
log data sets are opened and control blocks 



initialized. Upon subsequent entry, the 
currently recording data set (primaary) is 
closed and scheduled for queuing to the 
SYSOOT writer. The other data set becomes 
the primary data set and pointers are 
adjusted accordingly. Messages are written 
to the operator indicating the switch of 
data sets, or the failure of a data set to 
be opened, when an alternate data set is 
not available (usually because the data set 
is still being written by the system output 
writer) , the system log is temporarily made 
inactive. During the time that the log 
function is inactive, the buffer remains 
undisturbed and all incoming WTL macro 
instructions are reissued as WTO macro 
instructions to the primary /master console. 

Anytime the operating system enters step 
initiation and a log data set has been 
scheduled for queueing, the step initiation 
module IEFSD162 passes control to the Log 
Dispatcher lEEVLDSP. lEEVLDSP enqueues the 
log data set to a system output queue of a 
particular class and issues a corresponding 
message to the operator. 

After the log data set has been written, 
control is returned to the routine lEEV- 
LOUT, which opens and immediately closes 
the data set to reinitialize the TTRLL 
field (a field that describes the space 
available on the data set) . lEEVLOUT 
returns control to the SYSOUT Writer rou- 
tine that called it. 
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SECTION 8: CHECKPOINT/RESTART 



The Checkpoint/Restart facility allows a 
job to be restarted after ein abnormal ter- 
mination. The retry can begin at the start 
of a job step, or within a job step, and 
prior steps and portions of a step can be 
skipped if they executed successfully 
before the termination. The supervisor 
provides the following two type- 4 SVC rou- 
tines to handle restart within a job step 
(called a checkpoint restart) : 

• The Checkpoint routine, called by the 
CHKPT macro instruction (SVC 63) in the 
problem program at points where the 
programmer wishes a reexecution to 
begin . 

• The Restart routine (SVC 52), called by 
a job management routine when the 
restarting step is scheduled. 

Restart at the beginning of a step (a 
step restart) is handled by job manag^nent, 
and is documented in the MVT Job Management 
PLM. 



Core Image Records (CIRs) . The CIRs 
contain a copy of the caller's main 
storage region at the time he issued 
CHKPT. 



• Supervisor Records (SORs). The SURs 
contain the supervisor control blocks 
that will be needed to restart the 
task. 

The Checkpoint routine is logically 
divided into several functions, which are 
listed below with the names of load modules 
that implement them: 

• Checking parameters and system environ- 
ment (IGC0006C, IGC0106C, and 
IGC0206C) . The Housekeeping routine 
tests the CHKPT operands for validity, 
and ensures that the task is eligible 
for a checkpoint. A work area is 
obtained and formatted, the Job Control 
Table (JCT) is read in, and the CHR is 
built. 



The checkpoint routine creates a series 
of records (a checkpoint entry) in a data 
set provided by the calling task. The 
records include a copy of the task's main 
storage region, descriptions of data sets, 
and system control information. The 
Restart routine interprets the information 
in the checkpoint entry and uses it to 
restore the task to main storage, mount, 
verify and position its data sets, and give 
it control at the point where the check- 
point entry was written. 



CHECKPOINT (SVC 63) 



The Checkpoint routine is called by a 
problem program with the CHKPT macro 
instruction to create a checkpoint entry. 
The calling program supplies a DCB for the 
checkpoint data set and, optionally, a name 
(CHECK ID) for the entry. The Checkpoint 
routine writes four types of records in the 
checkpoint entry: 

• A Checkpoint Header Record (CHR) . The 
CHR describes a checkpoint and contains 
checkpoint/restart tables and flags. 

• Data Set Descriptor Records (DSDRs) . 
Each DSDR describes a data set and con- 
tains a job file control block (JFCB) , 
a JFCB extension, or the generation 
data group bias count table (GDGBCT) . 



Purging I/O requests (IGC0506C). The 
Check I/O routine removes the caller's 
pending I/O requests from the logical 
channel queues, and allows any active 
requests to complete. 

Describing the caller's data set status 
(IGCOA06C and IGCOD06C) . The Preserve 
routine writes out the CHR, and then 
builds and writes out a DSDR for each 
data set. 

Copying the caller's region (IGC0F06C, 
IGC0G06C, and IGC0H06C) . The Checkmain 
routine creates the CIRs by copying the 
caller's region(s), except for the 
checkpoint work area, into the check- 
point entry, and then builds and writes 
out the SURs from information in system 
control blocks. 

Reissuing the I/O requests (IGC0N06C). 
The Resume I/O routine returns the cal- 
ler's pending I/O requests to the log- 
ical channel queues. 

Clean up, report, and exit (IGC0Q06C 
and IGC0SO6C). The Checkpoint Exit 
routine returns the storage obtained 
with GETMAIN, returns the JCT to the 
input queue, writes a console message 
noting success or failure to write a 
checkpoint, closes the checkpoint data 
set if checkpoint opened it, and 
returns to the caller with an SVC 3 
(EXIT) instruction. 
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The first module of the Checkpoint rou- 
tine is loaded by the SVC SLIH, and subse- 
quent modules are called into the SVC tran- 
sient area by XCTL. Figure 8-1 shows the 
order in which the routines are executed, 
and the information each routine processes. 

If an error is detected at any point 
during checkpoint processing, the Check- 
point Exit routine is called. An error 
message is written, and an error code is 
returned to the caller, so that execution 
may continue without the checkpoint. 



PARAMETER AND ENVIRONMENT CHECK 

The first three load modules of the 
Checkpoint routine test the calling parame- 
ters and systan environment for conditions 
that would prevent successful checkpoint 
processing. If no errors are detected, a 
work area is obtained and formatted, and 
the JCT is read. A CHR is built in the 
output buffer, and the Check I/O routine is 
called. 



Parameter Check (IGC0006C> 

The first module sets the system mask to 
allow all interruptions, then inspects the 
checkpoint flag in the TCB to determine if 
checkpoint entries have been suppressed by 
the RD parameter of the job control state- 
ments. If they have been suppressed, SVC 3 
(EXIT) is issued to return to the caller. 
A test is also made for the CANCEL operand 
of the CHKPT macro Instruction, CANCEL 
processing is discussed below. 

For normal checkpoint processing, the 
first housekeeping module calls the super- 
visor's Validity Check routine (lEAOVLOO) 
to ensure that the addresses supplied for 
the checkpoint DCB and CHECKID field are 
within the problem program region. An 
invalid address prevents further process- 
ing, and the Checkpoint Exit routine is 
called. 

The checkpoint DCB, supplied by the 
caller, shows whether the checkpoint data 
set has been opened. If it has not, an 
OPEN is issued for it, and a flag is set 
indicating it must be closed before exit. 
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Then the size of the checkpoint work area 
is calculated by the following formula: 



WA = TIOT + 1108 + 48 (DEBs - 2) 



where; 



TIOT 



is the length of the Task I/O Table 
(dependent on the number of DD 
entries) . 



1108 

is a fixed table area. 

48 (DEBs - 2) 

is the number of Data Extent Blocks 
less two, times 48. 

A conditional GETMAIN, specifying Sub- 
pool 250, is issued for this area. If the 
GETMAIN is not successful, the Checkpoint 
Exit routine is called. If an area is 
returned, its upper and lower boundaries 
are checked to see that it does not come 
within 18 bytes of the region limits. 
(Because the work area is not copied into 
the checkpoint entry with the rest of the 
region, a 17 -byte or smaller "leftover" 
would be too small to write as a tape reco- 
rd.) If the work area is too close to the 
upper region boundary, all but the invalid 
pairt is released with FREEMAIN, and a 
second GETMAIN is issued. If the second 
GETMAIN is successful, the invalid portion 
of the first area is released. If the 
second GETMAIN is not successful, or if the 
first area returned is too close to the 
lower region boundary, the Checkpoint Exit 
routine is called, and no checkpoint entry 
is written. 

When the work area is obtained, the 
region boundaries, the address of the 
checkpoint DCB, and offsets to input buff- 
ers are stored in it, and the second house- 
keeping module is called. 



Environment Check (IGC0106C) 



The second housekeeping module tests 
characteristics of the checkpoint data set 
and the calling task for checkpoint suit- 
ability. If any error is detected, the 
Checkpoint Exit routine is called and no 
checkpoint is written. The invalid condi- 
tions, in the order tested, are: 

• Checkpoint data set not on a direct 
access or magnetic tape device. 

• Key length not equal to zero when the 
checkpoint data set is on a direct 
access device. 

• Record format is not "undefined." 



• Blocksize specified in the DCB is not 
zero or not greater than 600. 

• The data set was not opened for output. 

• Physical sequential or partitioned 
organization was not specified. 

• A timer interval is pending. 

• An IRB or SIRB is pending on the RB 
chain. 

• A Type 3 or 4 SVRB is pending (other 
than IGG0551A, EOV. ) 

• Rollout is being invoked. 

• The calling task is or has a subtask. 

• A WTOR is pending. 

• The CHECKID is missing, is too long, or 
contains invalid characters. 

In addition to these tests, a check is 
made for active ENQs. If any are pending, 
a warning message is issued, at completion 
of processing, informing the programmer it 
is the program's responsibility to reestab- 
lish the ENQs on a restart. 

If the caller has not specified the 
checkpoint entry blocksize in the DCB, a 
DEVTYPE macro instruction is issued to 
obtain the maximum blocksize for the 
device, which is entered in the DCB. (The 
blocksize will be reset to zero before 
return to the caller.) Normal exit from 
this module is to IGC0206C, for JCT 
processing. 

JCT Processing (IGC0206C) 

The third housekeeping module constructs 
a channel program and I/O control blocks in 
the work area, and reads in the JCT from 
the input queue. The Checkpoint Exit rou- 
tine is called if an I/O error occurs. 

The count of the number of checkpoints 
taken for the current job is incremented in 
the JCT, and, if no CHECKID was supplied by 
the caller, one is generated (C'C plus the 
seven-digit number of checkpoints taken) . 

A Checkpoint Header Record (CHR) , shown 
in Figure 8-2, is constructed in the work 
area and padded to 400 bytes with binary 
I's. The CHR is left in the output buffer 
and written later. Normal exit is to the 
Check I/O routine. 

CANCEL Processing 

The CANCEL operand of the CHKPT macro 
instruction indicates that the caller does 
not want a checkpoint entry to be created. 
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but wants to suppress an automatic restart 
at any preceding checkpoints. If CANCEL is 
specified, IGC0006C issues a GETMAIN for a 
small work area, and calls IGC0206C module 
to read the JCT. Control is then passed to 
the Checkpoint Exit module (IGC0Q06C), 
where the checkpoint taken flag is set off, 
the JCT is returned to the input queue, and 
control is returned to the caller. In case 
of a subsequent abnormal termination, there 
is no indication in the JCT that checkpoint 
entries exist for the failing step, and no 
checkpoint restart is performed. The 
entries are retained in the checkpoint data 
set; the programmer may restart the step 
from one of these entries by submitting the 
proper restart Job Control Language at a 
later time. 



PURGING I/O REQUESTS 

The Check I/O routine consists of one 
module, IGC0506C, which intercepts pending 
I/O requests initiated by the caller. 
Check I/O obtains a pointer to the chain of 
DEBs from the caller's TCB, and issues the 
PURGE macro instruction, specifying the 
QUIESCE option, for each DEB in the chain. 
The SVC Purge routine removes any I/O 
requests associated with the specified DEB 
from the Logical channel Queues of the I/O 
Supervisor. If a request has already been 
started, SVC Purge allows it to complete 
normally before returning to Check I/O. 

If an error occurs in completing an 
active I/O request for a QSAM or QISAM data 
set. Check I/O tests if the user has speci- 
fied the QSAM ACC option ("accept errors") 
in the DCB. If ACC is specified, the error 
is ignored. Otherwise, the Resume I/O rou- 
tine is called, and no checkpoint is writ- 
ten. An error message (IHJOOOI) is written 
to the operator indicating unsuccessful 
completion because of an I/O error. Data 
sets with other organizations are not 



checked for I/O errors. When all of the 
caller's I/O activity has subsided, the 
Preserve routine is called. 



DESCRIBING DATA SET STATUS 

The Preserve routine consists of two 
load modules, IGC0A06C and IGC0D06C. The 
first writes out the CHR already built (by 
IGC0206C) in the output buffer; the second 
builds and writes out Data Set Descriptor 
Records (DSDRs) for each data set. If 
either module detects an end-of -volume for 
the checkpoint data set on tape, IGC0206C 
is called to reprocess with a new tape. If 
the checkpoint data set is on a direct 
access device, or if end-of-volume is 
reached a second time on tape, the Resume 
I/O routine is called, and no further pro- 
cessing takes place. 

Writing Out the CHR (IGC0A06C) 

The Preserve routine writes out the CHR, 
which is always 400 bytes long. If the 
checkpoint data set is a partitioned data 
set, a NOTE macro instruction is issued, 
and the relative track address returned is 
saved in the work area. Control is passed 
to the second module. 

Building and Writing DSDRs (IGC0D06C) 

The second module of the Preserve rou- 
tine reads JFCBs from the input queue, 
obtaining the track addresses from the 
TIOT. For each JFCB, a Type 1 DSDR, con- 
sisting of a 2-byte identification 
(X'OOOO'), the 176-byte JFCB, the DDNAME, 
and the UCBTYP field from the UCB, is con- 
structed in the output buffer. If JFCB 
extensions are associated with the JFCB, 
they are read in, and a Type 2 DSDR is con- 
structed for each, consisting of the iden- 
tification X'0004', and the 176-byte JFCB 
extension. Whenever the 400-byte buffer is 
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filled, it is vrritten out to the checkpoint 
data set. When the end of the TIOT is 
reached. Preserve checks for the existence 
of a Generation Data Group Bias Count Table 
(GDGBCT) . If one exists, as many Type 3 
DSDRs as necessary to contain it are built 
and written. A Type-3 DSDR has the identi- 
fication code X'0008' and a 176- byte seg- 
ment of the GDGBCT. The format of the 
DSDRs is shown in Figure 8-3. Normal exit 
is to Checkmain. 



COPYING THE REGION 

The Checkmain routine consists of three 
load modules, IGC0F06C, IGC0G06C, and 
IGC0H06C. The first copies the caller's 
region into the Checkpoint data set as 
CIRs, and the second and third create SURs 
from the main storage supervision and con- 
tents supervision control blocks. Any I/O 
error within these modules causes the 
Resume I/O routine to be called, with an 
error code returned to the caller. If end- 
of- volume is detected on tape for the first 
time, control is transferred to IG0206C to 
attempt reprocessing with a new tape. If 
end-of-volume is detected on tape for a 



second time, or on a direct access device. 
Resume I/O is called with an error code. 



Writing CIRs (IGC0F06C) 

The first checkmain module determines 
the limits of the checkpoint work area, 
which is the only portion of the caller's 
main storage region vAiich is not written in 
the checkpoint entry. The first area 
copied is the portion of the region extend- 
ing from the top of the checkpoint work 
area to the upper limit of the region. The 
next portion copied is from the lower limit 
of the region up to the lower boundary of 
the work area. If necessary, storage 
assigned to the task in hierarchy one is 
copied last. Blocks are written out 
according to the blocksize supplied by the 
caller, or the maximum blocksize of the 
device, if the caller did not specify 
blocksize- Data is not moved to a buffer 
for writing, but is copied from its loca- 
tion in the region. The last record writ- 
ten out for each of the three storage areas 
shorter than the specified 
Such short records are extended 



is normally 

blocksize. 

to at least 18 bytes. 
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186 
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Type 3 DSDR 
2 
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Figure 8-3. Data Set Descriptor Records (DSDRs) 
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Building and Writing SURs (IGC0G06C and 
IGC0H06C) 

The SURs are constructed in a 200-byte 
output buffer in the work area, which is 
written out whenever it is full . The 
fields within the SDR may vary in content 
and length, so each is prefixed by a one- 
byte type code and one-byte length field as 
it is placed in the buffer. IGC0G06C first 
inserts the PQEs associated with the pro- 
blem program TCB, then the SPQEs and DQEs 
associated with the TCBs of the system task 
control routine, the initiator, and the 
problem program. Next the SVRBs and PRBs 
are added in the order they are found on 
the RB chain, and the LLEs are added last. 
IGC0H06C adds CDEs, the address of the PIE, 
the address of the first problem program 
save area from the TCB, the address of the 
pointer to the problem program save area 
from the TQE, the general registers from 
the checkpoint SVRB, each problem program 
DEB, any IRBs attached to these DEBs, the 
floating-point registers, the checkpoint 
DCB, the address of the SYNAD routine in 
the checkpoint DCB, and the TIOT. Normal 
exit is to the Resume I/O routine. 



RESTORING I/O REQUESTS 

The Resume I/O routine (1GC0N06C) 
searches through the chain of DEBs from the 
caller's TCB. If a DEB has an entry in the 
DEBUSRPG field, it indicates I/O requests 
were purged for that data set. Resume I/O 
issues a RESTORE macro instruction for each 
DEB with such an entry. The Restore rou- 
tine returns the purged I/O requests to the 
Logical Channel Queues of the I/O Supervi- 
sor. When all the DEBs have been checked, 
the Checkpoint Exit routine is called. 



CHECKPOINT EXIT ROUTINE 

The Checkpoint Exit routine is normally 
entered from the Resume I/O routine, but 
may be called from prior modules if an 
error is detected. The routine consists of 
two modules: IGC0Q06C, a general clean-up 
procedure, and IGC0S06C, a message routine. 

General Clean-up (IGC0Q06C) 

The first exit module checks to see if a 
checkpoint work area was obtained. If no 
work area exists, processing did not begin, 
and the message module is called to report 
the error and return to the caller. A test 
is also made for the CHKPT CANCEL operand. 
Processing for CANCEL was discussed above 
under "Parameter and Environment Check. " 

If the checkpoint entry was written, and 
the checkpoint data set has partitioned 
organization, a STOW macro instruction. 



specifying the CHECKID as manber name, is 
issued to add the entry to the data set 
directory. If no checkpoint entry was 
written because of an error, a FREEMAIN is 
issued for the checkpoint work area, and 
control is passed to the message module. 

The CHECKID is placed in the JCT to 
identify the most recent checkpoint entry 
for the job, and the checkpoint volume 
serial nianber or track address is placed in 
the appropriate JCT fields. (If automatic 
restarts have been suppressed by job con- 
trol statements, only the CHECKID is moved 
to the JCT.) The updated JCT is written 
out to the input queue, the checkpoint work 
area is returned via FREEMAIN, and the mes- 
sage module is called. 

Message Module (IGC0S06C) 

The last checkpoint module issues a GET- 
MAIN for a message buffer and small work 
area, and determines the type of message to 
be issued from the return code and error 
code passed in the extended SVRB save area. 
One of the following messages may be writ- 
ten: IHJOOOI, IHJOOII, IHJ002I, IHJ004I, 
or IHJ005I. The jobname, checkpoint 
DDNAME, and, if a checkpoint entry was 
created, the volume serial number, unit 
name, and CHECKID of the entry, are moved 
into the message area, and a WTO macro 
instruction is issued. 

If the Housekeeping routine opened the 
checkpoint data set, a CLOSE is issued. 
The message area is released via FREEMAIN, 
and one of the following return codes is 
placed in Register 15: 

X'OO' Valid CHECKPOINT entry written. 

X'08' No CHECKPOINT written, calling 
error. 

X'OC Permanent I/O error. 

X'lO' A valid CHECKPOINT entry was writ- 
ten, but there were outstanding 
ENQs. It is the responsibility of 
the user to restore these ENQs at 
RESTART . 

SVC 3 (EXIT) is then issued to return to 
the Dispatcher. 



RESTART (SVC 52) 



Restart of a program within a job step 
is accomplished by using the information 
stored in a checkpoint entry to recreate 
the conditions that existed when CHKPT was 
issued. Interpretation of the checkpoint 
entry is done by both job management and 
supervisor routines. When the step to be 
restarted is scheduled, job management 
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inserts an extra job step (lEFDSDRP) in 
front of it, which adjusts the input queue, 
and reads the DSDRs to build JFCBs for the 
restarting step's data sets. lEFDSDRP also 
ensures device allocations that are compat- 
ible with those that existed at CHKPT time. 
Just before exit, lEFDSDRP changes the name 
of the restarting step to lEFRSTRT. When 
this program is brought into storage and 
given control, it issues SVC 52, causing 
the first load module of the Restart rou- 
tine to be brought into an SVC transient 
area. The first load of the restart rou- 
tine is used by job management routines. 
During the actual restart, it transfers 
control to the housekeeping routines. 
Restart uses the TCB and other control 
blocks assigned to lEFRSTRT to recreate the 
system environment for the restarting step. 



• Restoring the step to main storage 
(IGC0505B, IGC0605B, IGC0705B, 
IGC0805B, and IGC0905B) . The Repmain 
routine reads the CIRs to restore the 
step to its region in main storage, and 
processes the SURs to rebuild the task 
supervision control blocks and queues. 

• JFCB Processing (IGC0G05B, IGC0G95B, 
IGC0I05B, and IGC0H05B) . The JFCB pro- 
cessor interprets the JFCBs (already 
rebuilt by lEFDSDRP) and builds tables 
describing each open data set in the 
restart work area. 

• TCAM Processing {IGC0J05B) . The TCAM 
Data Set Processor initializes the TCAM 
region, sets up TCAM control blocks, 
and queues for each TCAM data set that 
is to be restarted. 



The major functions of restart, and 
their relationship to the job management 
routines and the checkpoint entry, are 
shown in Figure 8-4. The functions are 
listed below, with the names of the load 
modules implementing them: 



Mounting and verifying volumes 
(IGC0K05B and IGC0M05B) . The Mount/ 
Verify routine processes volume labels 
(calling a user label routine if neces- 
sary) , and requests the operator to 
mount missing volumes. 



Obtaining and formatting storage 
(IGC0105B and IGC0205B) . The House- 
keeping routine issues a GETMAIN for 
storage in the problem program region, 
builds work tables and buffers for the 
following routines, and positions the 
checkpoint entry to the first CIR. 



Processing SYSIN/SYSOUT non-DASD data 
sets (IGC0L05B). The SYSIN/SYSOUT Non- 
Direct Access Data Set Processor primes 
the buffers for a SYSIN data set from 
the card reader, or writes header 
labels on a SYSOOT tape data set with 
deferred restart. 
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Figure 8-4. Restart Processing Routines 
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• Positioning open data sets (IGC0N05B, 
IGCOQ05B, IGC0P05B, IGC0R05B, IGC0S05B, 
and IGC0U05B) . The Data Set Processor 
adjusts the problem program's data sets 
to the record being processed when 
CHKPT was issued. 

• Processing ISAM or BDAM data sets 
(IGC0W05B). The ISAM and BDAM Data Set 
Processors prepare ISAM and BDAM data 
sets for restart processing. 

• Restarting I/O requests (IGC0T05B). If 
the problem program had I/O requests 
pending when CHKPT was issued, the 
Access Method-Disposition routine 
returns these requests to the Logical 
Channel Queues to be restarted. This 
routine also adjusts Partitioned Data 
Set directories. 

• Returning control to the step 
(IGC0V05B)- The Restart Exit routine 
frees the restart work area, writes a 
message to the console, and returns 
control to the restarting step through 
the Dispatcher. 



OBTAINING AND FORMATTING STORAGE 

The Housekeeping routine consists of two 
load modules, IGC0105B and IGC0205B. The 
first obtains storage, transfers informa- 
tion into it, and opens the checkpoint data 
set. The second constructs the I/O blocks 
and channel programs needed to read the 
checkpoint entry. 

Obtaining Storage (IGC0105B) 

The first load module of Restart House- 
keeping receives a parameter list in the 
extended SVRB save area containing informa- 
tion from the checkpoint header record and 
DSDRs, processed by lEFDSDRP. From this 
parameter list, the Housekeeping routine 
obtains the limits of the restarting step's 
region, and issues a GETMAIN for all of it. 
The parameter list also contains a pointer 
to the checkpoint work area within the 
region, and Restart Housekeeping sets up 
the same area as a work area. A BSAM DCB 
for the checkpoint data set is constructed 
in the work area, and an OPEN is issued. 
Part of the problem program region is tem- 
porarily freed with FREEMAIN for the OPEN 
routine. The second module of the House- 
keeping routine is called after the OPEN. 

Checkpoint Data Set Initialization 
(IGC0205B) 

The second Housekeeping routine module 
moves the checkpoint data set lOB and chan- 
nel program to the work area. If the data 
set is on a tape device, successive records 
are read until the tape is positioned at 



the first CIR. If the data set is on a 
direct access device, a POINT macro 
instruction is issued to position the data 
set at the first CIR. Exit is to the 
Repmain routine. 



RESTORING THE STEP TO MAIN STORAGE 

The Repmain routine consists of five 
modules (IGC0505B, IGC0605B, IGC0705B, 
IGC0805B, and IGC0905B) . The first copies 
the CIRs into their original positions in 
the step's region; the other four read and 
process the SURs to recreate the system 
control blocks and queues that existed for 
the restarting task at CHKPT time. An I/O 
error or end-of-volume in any of the 
modules causes transfer to the Restart Exit 
routine for termination. 

Restoring Main Storage tIGC0505B) 

The first module of the Repmain routine 
reads CIRs into the areas of main storage 
from which they were written. The first 
CIRs are read into the area between the 
upper limit of the restart work area (which 
corresponds to the checkpoint work area) 
and the top of the region. The second area 
copied is from the lower limit of the 
region to the bottom of the restart work 
area. Hierarchy 1 is restored last, if 
present. The first Repmain module also 
restores the PQEs, the SPQEs and the DQEs 
for the TCBs of the initiator, the system 
task control routine, and the restarting 
task. These elements are the first fields 
in the SURs. 

SDR Processing (IGC0605B, .IGC0705B, 
IGC0805B, IGC0905B) 



The other Repmain modules continue the 
processing of the SURs. The contents 
supervision blocks are replaced with the 
saved CDEs, Extent List, and LLEs. The 
contents supervision blocks are then freed. 
Internal queue pointers within these blocks 
are adjusted as they are returned to system 
queue space. Finally the current TCB 
(originally assigned to lEFRSTRT) is 
updated with the information saved from the 
restarting task's TCB. The TIOT is the 
last control block read in, before control 
is passed to the JFCB Processing routine. 
If an I/O error or EOV occurs, control 
passes to IGC0905B which frees all partial- 
ly restored chains. 



JFCB PROCESSING 

This routine counts the data sets that 
were open at CHKPT time, and builds a data 
set description table in the restart work 
area for each data set. In another part of 
the work area, a set of I/O control blocks 
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(DCB, lOB, DEB, and a channel program) is 
constructed for each data set. The JFCBs 
processed were constructed from the DSDRs 
in the checkpoint entry by lEFDSDRP. The 
first two modules of the JFCB Processing 
routine (IGC0G05B and IGC0G95B) build the 
tables and control blocks, the third (IGC- 
0IO5B) makes adjustments for data sets 
residing on more than five volumes. If 
there are TCAM data sets, IGC0J05B is 
executed before IGC0I05B. IGC0H05B 
receives control if any data set descrip- 
tion tables correspond to a dummy data set. 



Table Complete Module (IGC0I05B) 

The last JFCB processing module reads 
the JFCB extension for those data sets 
residing on more than five volumes. For 
non-concatenated partitioned data sets and 
sequential data sets, the volume in use at 
CHKPT time is placed at the top of the 
description table list of volumes, and it 
is the only one mounted later. A flag is 
set for multi-volume ISAM, BDAM, and conca- 
tenated partitioned data sets to indicate 
that all volumes on ^ich they reside will 
have to be mounted. 



Table Build Module (IGC0G05B) 

This JFCB Processing module assigns a 
30U-byte section within the restart work- 
area to each DEB chained to the restarting 
task's TCB. Then the "new" TIOT is 
seeirched for the DDNAME corresponding to 
each open data set. 



Table Build Module (IGC0G95B) 

This JFCB processing module obtains the 
disk addresses from the TIOT, and the JFCBs 
are read in. If an I/O error occurs, or a 
DDNAME is missing, control is passed to the 
Restart Exit routine. When all JFCBs have 
been read in, a DCB, DEB, lOB, ECB, and 
channel program are constructed for each 
data set. For non-TCAM data sets, up to 
five volume identifications are moved from 
the JFCB to the associated data set 
description table, and a flag is set if it 
will be necessary to read JFCB extensions 
later for additional volumes. 



For TCAM data sets, the queue name is 
saved in the associated data set descrip- 
tion table and the TCAM flag is set to in- 
dicate that TCAM processing is required. 
If the TCAM flag is set, IGC0G95B passes 
control to the TCAM Data Set Processor 
(IGC0J05B). Otherwise, it passes control 
to IGC0I05B. 



TCAM Data Set Processor Module (IGC0J05B) 

If there are any TCAM data sets to be 
restarted, the TCAM data set processor 
receives control from IGC0G95B. It initia- 
lizes the TCAM region and sets up TCAM con- 
trol blocks and queues for each data set. 
Control passes to the Restart Error routine 
(IGC0V05B) if the TCAM message control pro- 
gram is not active in the system, the data 
set' s QNAME parameter is not known to TCAM, 
the process entry defined by QNAME is 
already being used, or a GETMAIN by TCAM 
was unsuccessful. If IGC0J05B executes 
normally, control passes to the last JFCB 
Processor (IGC0I05B) . 



Dummy Data Set Processor (IGC0H05B) 

This module receives control from IGC- 
0I05B if any of the data set description 
tables correspond to a dummy data set. 
(For a discussion of dummy data sets, refer 
to Job control Language Reference .) 

For each dummy data set encountered, a 
check is made to determine if the data set 
was a dummy data set when the checkpoint 
was made. If it was, no further processing 
is done. 

For each dummy data set that was not a 
dummy data set when the checkpoint was 
taken, IGC0H05B (1) deletes the subroutine 
loaded by the OPEN macro instruction, and 
(2) unchains and frees the DEB associated 
with the data set. If (1) the data set was 
being processed by the queued sequential or 
basic sequential access methods and (2) the 
checkpoint was not made during an end-of- 
volume exit for the data set, then IGC0H05B 
frees the lOBs created by the OPEN macro 
instruction, creates a dummy DEB and adds 
it to the DEB chain, loads the dummy access 
method (IGC019AV) , and sets pointers to it 
in the DCB associated with the data set. 

An error condition exists if (1) a data 
set that has been made a dummy is not being 
processed by either the basic sequential or 
the queued sequential access methods at the 
time the checkpoint was made or (2) the 
checkpoint was made during an end-of-volume 
exit. When an error occurs, an error code 
of 79 is placed in the restart work area. 

If no errors are detected, control is 
passed to the mount verification portion of 
the Restart routine once all of the table 
entries have been processed. 

If an error has been detected, control 
is passed to the Restart Error routine 
(IGC0V05B) . 



MOUNTING AND VERIFYING VOLUMES 

The Mount /Verify routine ensures that 
the correct volumes are mounted for the 
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user's data sets, and requests the operator 
to mount any that are niissing. The user's 
non-standard tape label routine is called 
to verify data sets with non-standard 
labels. The routine consists of two 
modules: IGC00K05B, which processes all 
data sets not on a direct access device, 
and IGC0M05B, for direct access device data 
sets. 

Non- Direct Access Processing (IGC0K05B) 

The non-direct access Mount/Verify 
module checks each of the data sets 
description tables, and processes all 
except those for direct access data sets 
and null data sets. For SYSIN, SYSOUT, 
unit record, and graphic data sets, the DEB 
is adjusted, and no mount verification is 
performed. 

For data sets on magnetic tape, the 
volume serial number in the data set' s 
description table (the number saved at 
CHKPT time) is compared to the volume seri- 
al number in the primary UCB specified by 
the data set's TIOT entry. If the volume 
serial numbers do not match, the secondary 
UCBs, if any are checked. If no match is 
found, a suitable UCB is selected from the 
TIOT list, and the operator is requested to 
mount the volume. 

When the volume serial number is 
located, or when the volume is mounted, the 
tape label is read and checked, and the 
tape is rewound. If it is not the correct 
volume, or if a standard label is present 
and the JFCB indicates it should not be, a 
message is written to the operator, and the 
tape is unloaded. If it is the correct 
volume, the UCB and DEB are adjusted, and 
the UCB becomes the primary UCB in the TIOT 
entry. 

When the end of the description tables 
is reached, a second pass is made through, 
checking for input volumes with non- 
standard labels. A user-supplied label 
verification routine is called if any are 
present. On completion, the direct access 
Movmt/Verify module is called, unless there 
are no direct access data sets. In this 
case the first Position I/O module is 
called. 

Direct Access Mount/Verify Module 
(IGC0M05B) 

The second module of the Mount/Verify 
routine compares the volume serial number 
in the data set description table (saved at 
CHKPT) with the volume serial number in the 
primary UCB listed in the TIOT entry for 
each direct access data set. If the num- 
bers match, the DEB and DCB are adjusted. 
If the numbers do not match, the secondary 
UCBs listed in the TIOT are checked. If no 



match is found, a suitable UCB is selected, 
and the operator is requested to mount the 
volume . 

For sequential and single partitioned 
data sets, only the volume in use at CHKPT 
time is mounted. All volumes on which 
ISAM, BDAM, or concatenated partitioned 
data sets reside are mounted. If neces- 
sary, JFCB extensions are read to find the 
volume identifications. 

If an error occurs in either of the 
^tount/Verify modules. Restart is terminated 
by calling the Exit routine. If no error 
occurs, control is passed to the Data Set 
Processor routine. The tape module is 
called first, unless all data sets are on 
direct access devices. 

SYSIN/SYSOUT Non-Direct' Access Data Set 
Processor (IGC0L05B) 

This receives qontrol from module 
IGC0K05B or IGC0M05B for certain SYSIN or 
SYSOUT data sets. It primes the buffers 
for a SYSIN data set from the card reader, 
or writes header labels on a SYSOUT tape 
data set with deferred restart- If an 
ASCII label is used for a SYSOUT tape or an 
error occurs in writing the SYSOUT header 
labels, control goes to the Restart Exit 
routine (IGC0V05B) . Otherwise control goes 
to IGC0N05B (for SYSIN/SYSOUT data sets on 
direct access) or IGC0P05B. 



POSITIONING OPEN DATA SETS 

SYSIN/SYSOUT Data Set Processor 1 
(IGC0N05B) 

This module adjusts the DCB, DEB and 
channel programs for SYSIN or SYSOUT direct 
access data sets on a deferred restart. 
These data sets which existed at the time 
checkpoint was issued have been deleted, 
and new SYSIN or SYSOUT data sets have been 
allocated at restart time. The name of the 
reallocated data set is obtained from the 
JFCB, and the VTOC is searched for the 
DSCB. Extents from the DSCB are used to 
construct a new DEB. If the number of 
extents in the DSCB equal the number of 
extents in the old DEB in use at checkpoint 
time, the new DEB is constructed in the 
same space as the old DEB. Otherwise, GET- 
MAIN is issued to obtain space for the new 
DEB, and the old DEB space is freed. 

For SYSIN data sets, the following abso- 
lute disk addresses (MBBCCHHR) that point 
to the old data set are changed to absolute 
disk addresses that point to the same posi- 
tions in the new data set: 

1. Full disk address in the DCB - This 
address is changed to point to the 
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next record to be read from SYSIN in 
the new data set. 

2- lOB seek addresses of the current and 
next lOB - At Restart time, these 
addresses point to the old data set 
(because the channel program for the 
next read is built during the current 
read) and now are changed to point to 
the new data set. 

The old disk addresses (MBBCCHHR) are con- 
verted into TTR form using the old DEB; 
after the new DEB is constructed, the 
addresses are converted back into MBBCCHHR 
form using the new DEB. The TTR to 
MBBCCHHR conversion is performed in the 
next module, IGC0Q05B. 

SYSIN/ SYSOUT Data Set Processor 2 (Direct 
Access) (IGC0Q05B) 

This module calculates the number of 
tracks in each extent in each SYSIN or SYS- 
OUT DEB and places the number in the DEB. 
For SYSOUT data sets, the lower limit of 
the first extent is placed in the full disk 
address field of the DCB; the track capaci- 
ty for the device is also placed in the 
DCB. For SYSIN data sets, the absolute 
disk addresses which were converted to TTR 
form in IGC0N05B are now converted back to 
MBBCCHHR form using the new DEB. Control 
is then passed to Data Set Processor 1 
(IGC0P05B) if there are any non-direct 
access data sets. Otherwise, control 
passes to Data Set Processor 2 (IGCOROSB). 

Data Set Processor 1 (IGC0P05B) 

IGC0P05B is the non-direct access table 
reformatting module. There is a table ele- 
ment entry in the Restart work area for 
each data set that is open when a CHKPT 
macro instruction was issued. There are at 
least two areas of 30U bytes each, located 
after the table elements, which contain a 
DEB, DCB, ECB, lOB, Channel Program, and 
JFCB. IGC0P05B counts the number of tape 
data sets, indicated by the table elements, 
and tries to reformat the 3 04- byte areas to 
contain 128 bytes for each tape data set 
(eliminating the JFCB) . If more space is 
needed for 128-byte areas than is contained 
in the area occupied by the 304-byte areas, 
IGC0P05B issues a conditional GETMAIN macro 
instruction for additional storage. If 
this storage is not available, all tape 
data sets cannot be repositioned simul- 
taneously. Control then passes to 
IGC0S05B. 

Data Set Processor lA (IGC0S05B) 

This module works from the data set 
description tables, processing all magnetic 
tape data sets except those tapes created 
under DOS which contain either embedded 



checkpoint records or possibly a leading 
tapemark. On entry, all but two types of 
tape volumes are positioned at the load 
point. The exceptions are SYSIN data sets, 
which are positioned to read the first user 
input record, and non-standard labeled 
tapes, which are positioned at the first 
data record by the user label routine. 

Data Set Processor lA first advances the 
tape past the label, if necessary, to the 
correct data set, using the file sequence 
number. Then the DCB block coumt field 
(DCBBLKCT) , saved at CHKPT, is used to 
advance the data set to the correct record. 
If the BLKCT field is zero or negative, the 
data set is positioned at the first record 
or end-of-file, depending whether the for- 
ward or backward processing was taking 
place at CHKPT time. An I/O error in repo- 
sitioning causes Restart termination. 
IGC0S05B passes control to the DOS Tape 
Data Set Processor (IGC0U05B) if any data 
sets are open at CHKPT time for which eith- 
er a leading tapemark or embedded DOS 
checkpoint record is indicated. 

DOS Tape Data Set Processor (IGC0U05B) 

This module is called to position tapes 
created under DOS which contain either a 
leading tapemark or embedded checkpoint 
record. Positioning of these tapes occurs 
similarly as in IGC0S05B with two 
exceptions: 

1. For the indication of a leading tape- 
mark, a read is issued and the result- 
ing status is tested for indication of 
a unit exception. If a tapemark is 
not sensed, the tape is repositioned 
to the load point prior to performing 
record positioning. 

2. To perform record positioning of data 
sets containing DOS embedded check- 
point records requires the reading of 
the first 20 bytes of every block. 
During record positioning, the 
embedded checkpoint records encoun- 
tered are spaced over and are not 
reflected in the block count. 

Data Set Processor 2 (IGC0R05B) 

This module is called from IGC0S05B 
except when the above described DOS tape 
volumes require positioning. If either of 
these tape volumes requires positioning. 
Data Set Processor 2 is called from IGC- 
0U05B. If there are no direct access data 
sets, the Access Method-Disposition module 
(IGC0T05B) gains control. 

Data Set Processor 2 (IGCOROSB) checks 
each data set residing on a direct access 
device for a difference in the space allo- 
cation limits in the DEB saved at CHKPT 
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time, and the space allocation limits in 
current data set control blocks (DSCBs) in 
the volume table of contents (VTOC) . Any 
discrepency between a DEB and the asso- 
ciated DSCB for input data sets causes 
Restart termination, since the data set has 
been modified since CHKPT. 

For output data sets, the smaller of the 
two space allocations is placed in both the 
DEB and the DSCB- If the DSCB extents are 
reduced, the Partial Release module of the 
CLOSE routine is called to return the 
released space to the free area on the 
volume. ENQ and DEQ are used to protect 
the VTOC from other users during any modi- 
fication. When all direct access data sets 
have been checked, the Access Method- 
Disposition module is called. 

ISAM and BDAM Data Set Processor (IGC0W05B) 

If there are any ISAM or BDAM data sets 
to be restarted, this module receives con- 
trol from Data Set Processor 2 (IGC0R05B). 
For ISAM data sets, it reads the Format 2 
DSCB and then transfers control to ISAM 
Open (IGG01920 or IGG01950) to validate 
certain pointers in the DSCB. If an I/O 
error occurs in the ISAM open module it 
sets a return code and IGC0W05B gives con- 
trol to the Restart Exit routine 
(IGC0V05B)- For BDAM data sets, IGC0W05B 
reinitializes addresses within reentrant 
BDAM access method modules. It passes con- 
trol to the I/O Restart routine (IGC0T05B) . 



than that of the member being processed at 
CHKPT, it is deleted, using the STOW macro 
instruction. 

After all partitioned data sets have 
been checked, the chain of DEBs associated 
with the problem program TCB is inspected 
for entries in the DEBUSRPG field. These 
entries point to a chain of lOBs for user 
I/O requests which were pending at CHKPT 
time. The RESTORE macro instruction is 
issued for each DEB with intercepted 
requests. This returns the I/O requests to 
the I/O Supervisor's logical channel 
queues, where they are started. Control 
then passes to the Exit module. 



RESTART EXIT ROUTINE 

The Restart exit module (IGC0V05B) tests 
the error code field in the restart work 
area to determine if entry was caused by an 
error in one of the earlier modules. If an 
error code is present the exit routine 
places it in the "nn" field of the console 
message IHJ007I. The message is written 
with WTO, and ABEND is issued to return to 
the Dispatcher. 

If no error code is found, WTO is used 
to write console message IHJ008I. The 
restart work area is released with FREE- 
MAIN, and if the checkpoint routine opened 
the checkpoint data set, the restart exit 
routine issues a CLOSE for it. 



RESTARTING I/O REQUESTS 

The Access Method-Disposition module 
(IGC0T05B) checks each output partitioned 
data set for members added since CHKPT was 
issued. The partitioned data set directory 
is read, and if the relative track and 
record address of any member is greater 



The exit routine places a return code of 
X'O**' in register 15 to inform the restart- 
ing program that a restart has taken place, 
and exits with an SVC 3 (EXIT) . Since the 
TCB and SVRB have been updated with infor- 
mation saved at CHKPT time, the problem 
program will be started as though CHKPT had 
just been issued. 
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SECTION 9: 



EXITING PROCEDURES 



Exiting procedures consist of the prepa- 
ration for return and the actual return of 
control from a completed program or rou- 
tine. The program may be a user or system 
program that has issued a RETURN macro 
instruction, a completed SVC routine, or a 
user (asynchronous) exit routine. Control 
may pass to a user program or to a supervi- 
sor termination routine that performs nor- 
mal termination of the completed program's 
task. Exiting procedures fall into three 
main classes: 

• Preparing for return from a type-1 SVC 
routine. This class of exiting proce- 
dure is performed by the Type-1 Exit 
routine. 



program ready, thus requiring a task 
switch. The Type-1 Exit routine recognizes 
this condition by testing the doubleword 
TCB pointers lEATCBP and IEATCBP+4. If 
both pointers contain the address of the 
current TCB, no task switch is required; 
the Type-1 Exit routine restores registers 
from lower main storage and returns control 
to the caller. If the two pointers are not 
equal, a task switch has been indicated, 
and the Type-1 Exit routine must branch to 
the Dispatcher. Before branching, the 
Type-1 Exit routine saves the SVC old PSW 
in the current request block, and the con- 
tents of the caller's registers in the cur- 
rent TCB; this is for eventual return to 
the caller. 



• Preparing for return from all other 
types of programs. This class of exit- 
ing procedure is performed by the Exit 
routine. 

• Performing the actual return of con- 
trol. This class of exiting procedure 
is performed by the Dispatcher (except 
when the return is from a type-1 SVC 
routine that returns control directly 
to the caller) . 



HANDLING RETURN FROM TYPE-1 SVC ROUTINES 

The Type-1 Exit routine handles the 
return to a user program from a completed 
type-1 SVC routine. It determines whether 
control should be returned directly to the 
caller of the SVC routine, or to the Dis- 
patcher. Control passes to the Dispatcher 
if the completed SVC routine has indicated 
the need for a task switch by altering the 
"new" TCB pointer, lEATCBP. 

The Type-1 Exit routine is entered from 
any type-1 SVC routine via a branch. Its 
first step, a housekeeping step, is to 
reset the "type-1 switch" to indicate that 
registers are no longer stored in the lower 
main storage save area. The ABTERM routine 
tests this switch during an abnoirmal task 
termination to determine whether the rou- 
tine that called the ABTERM routine is a 
type-1 SVC routine. 

The Type-1 Exit routine then determines 
whether to return control directly to the 
caller or to branch to the Dispatcher; it 
does this by testing if the exiting SVC 
routine has indicated the need for a task 
switch. Some type-1 SVC routines, such as 
the Wait and Post routines, normally place 
a program in a wait condition or make a 



In MVT with Model 65 multiprocessing, 
the Type-1 Exit inspects the doubleword TCB 
pointers of both CPUs. If the TCB pointers 
for a CPU are unequal, a task switch is 
required, and the Dispatcher must be 
entered. The Dispatcher is also entered if 
the External FLIH bit in FLRETFLG is set, 
indicating that an external interruption 
has not been processed (in which case the 
Dispatcher passes control to External 
FLIH) . In addition, the Dispatcher places 
zeros in the supervisor lock and CPU 
affinity bytes before returning control to 
the caller to show that neither CPU con- 
trols disabled Supervisor code if the SVC 
old PSW is completely enabled for interrup- 
tions. A completely enabled SVC old PSW 
indicates that the system was unlocked dur- 
ing the calling routine and must be 
returned to an unlocked state after comple- 
tion of the Type-1 SVC routine. 



PREPARING FOR RETURN FROM PROGRAMS OTHER 
THAN TYPE-1 SVC ROUTINES 

The Exit routine, itself a type-1 SVC 
routine, handles the exiting procedures for 
all programs other than type-1 SVC rou- 
tines. User or system programs gain 
supervisor-assisted Linkage to the Exit 
routine by issuing a RETURN macro instruc- 
tion; SVC routines obtain a similar result 
by using an SVC-3 instruction. The Exit 
routine determines the type of program that 
is exiting. The program can be a user 
program-check exit routine, a user asyn- 
chronous exit routine, an SVC routine, or a 
user program. For each type of exiting 
program, some special processing is 
performed . 

If the completed program was the first 
executed program of its task, and therefore 
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is considered to be at the "highest control 
level" within that task, the Exit routine 
recognizes an end-of-task condition, and 
branches to the End-of-task routine (EOT) 
to perform normal termination of the call- 
er's task. 

Upon receiving control back from EOT, or 
if an End-of-task condition does not exist, 
the Exit routine dequeues the RB under 
which the completed program was operating 
for all types of completed programs except 
user program check routines, which have no 
RBs. If the EB had been dynamically 
acquired via a GETMAIN macro instruction, 
the Exit routine frees the space occupied 
by the RB. 

When it has completed its processing, 
the Exit routine branches to the Transient 
Area Refresh routine, which determines 
whether an SVC routine that was overlaid in 
its transient area block (TAB) may be 
restored to the block. The process of 
restoring an overlaid SVC routine is called 
"refreshing" the TAB. If a TAB may be 
refreshed, the Transient Area Refresh rou- 
tine initiates the refresh process before 
branching to the Dispatcher. If no SVC 
routines were using a TAB, no processing 
occurs, and the Transient Area Refresh rou- 
tine branches to the Dispatcher. 



PREPARING FOR RETURN FROM A USER PROGRAM 
CHECK ROUTINE 



The Exit routine then transfers register 
contents and the RB old PSW, belonging to 
the user program that had been interrupted 
by the program check, to the current RB. 
The Exit routine sets up the right half of 
the RB old PSW in the program's RB from 
information stored in the PIE. It sets up 
the left half of the PSW by transferring 
information from the left half of the SVC 
old PSW, which was stored when the user 
program check routine issued a RETURN macro 
instruction. The reason for constructing 
the RB old PSW from these two different 
sources is that (1) the user program check 
routine has the option of specifying a 
return point in the interrupted program 
that is different from the point of inter- 
ruption, and therefore may store this 
return address in the right half of the 
program old PSW in the PIE; and (2) the 
user program check routine may have acci- 
dently altered the left half of the program 
old PSW stored in the PIE. 

After transferring register contents to 
the TCB and setting up the RB old PSW in 
the RB, the Exit routine branches to the 
Dispatcher, which returns control to the 
interrupted user program. The Dispatcher 
loads the user's register contents from the 
current TCB and loads the RB old PSW set up 
by the Exit routine in the RB. This branch 
to the Dispatcher is an exception to the 
normal procedure of branching to the Tran- 
sient Area Refresh routine- 



The Exit routine tests whether to per- 
form special processing needed during the 
return from a user program check routine. 
When a user program check routine issues a 
RETURN macro instruction, a branch to an 
SVC- 3 instruction results. The SVC 
instruction is located in lower main 
storage, just before the entry point to the 
Program Interruption FLIH. When the SVC 
interruption occurs, the address of the 
next executable instruction (the entry 
point of the Program Interruption FLIH) is 
placed by the CPU in the SVC old PSW. The 
Exit routine compares the address in the 
SVC old PSW with the address in the program 
interruption new PSW; if the two addresses 
are equal, the return is from a user pro- 
gram check routine. 

The Exit routine clears the "first-time 
logic" switch in the user's program inter- 
ruption element (PIE). The first execution 
of the SPIE routine for the current task 
had created a PIE, in which the program old 
PSW and certain registers are stored during 
a program interruption. The "first-time 
logic" switch must be cleared to indicate 
to the Program Interruption FLIH that the 
PIE is not active; without such a resetting 
of the switch, the FLIH would interpret a 
second program interruption as occurring in 
the program check routine, and would cause 
abnormal termination of the current task. 



PREPARING FOR RETURN FROM PROGRAMS 
CONTROLLED BY RBS 

If the returning program is not a user 
program check routine, the Exit routine 
examines the STAE control block (SCB) queue 
pointed to by the TCBNSTAE field in the 
TCB. If there are no SCBs or if ABEND is 
in progress, the SCB processing is bypassed 
and Exit determines the RB type as 
described below. Exit removes from the 
queue and frees all SCBs for the exiting 
program except those SCBs for which the 
exiting program issued a STAE (Specify Task 
Abnormal Exit) macro instruction with the 
XCTL option. The search of the queue ter- 
minates when an SCB is found for an RB 
other than the RB for the exiting program. 
When the RB that is exiting is the last PRB 
(EOT condition) , Exit frees all SCBs 
including STAI SCBs. 

If there are no SVRBs (except possibly 
the exiting RB) queued to the TCB, the 
"prevent terminal attention exits" bit in 
the TCB is turned off. 

The Exit routine then determines the 
type of program that is exiting by examin- 
ing the RBSTAB field of its associated 
request block. This RB is always first on 
the RB queue when the Exit routine is 
entered. Depending on the type of RB, the 
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Exit routine perforins one of three general 
types of processing. 

• If the RB is an SVRB, representing a 
type 2, 3, or H SVC routine, the Exit 
routine branches to the SVC Second 
Level Interruption Handler to perform 
special handling for transient 
routines. 

• If the RB is an SIRS or an IRB, repre- 
senting a user exit routine, the Exit 
routine perforins special processing for 
exit routines. 

• If the RB is a PRB, representing a user 
program, the Exit routine performs an 
exiting procedure needed for contents 
supervis i on . 

If the Returning Routine Is an SVC Routine 



ling the exiting routine. If it is, it is 
dequeued. If it is not, the SVRB repre- 
sents another request for the routine, and 
the TAHEXIT subroutine cannot flag the 
transient area as free. In either case, 
the entire queue is checked. 

When the end of the queue is reached, 
the TAHEXIT subroutine decreases by one the 
count of the total number of users of all 
the transient areas. This count is used by 
the Transient Area Refresh routine to 
determine if a search for a routine that 
should be refreshed is necessary. 

The TAHEXIT subroutine flags the asso- 
ciated TACT entry either "in use" or 
"free," according to whether or not another 
SVRB for the exiting routine is still in 
the user queue. The TAHEXIT subroutine 
then returns control to the Exit routine. 



For an SVC routine, the Exit routine 
branches to the TAHEXIT subroutine (entry 
point lEAQTROl) . The TAHEXIT subroutine 
performs two functions. (1) It moves saved 
registers from the SVRB to its TCB, and 
stores registers 0, 1, and 15 in the TCB. 
It does this so that the caller of the SVC 
routine will be redispatched with the prop- 
er register values- (2) It removes the 
SVRB for an exiting transient routine from 
the transient area queues. Both functions 
are performed if the exiting program is a 
treinsient SVC routine. 

The TAHEXIT subroutine manipulates the 
register save areas so that when the caller 
of the exiting SVC routine is reentered, 
its registers 2-lU contain the same values 
they had when the SVC was issued. Regis- 
ters 15, 0, and 1 contain the values which 
the SVC routine provided — normally para- 
meters passed back to the caller. 

If the exiting routine is resident (type 
2), the TAHEXIT subroutine returns control 
to the Exit routine. But if the exiting 
routine is nonresident, TAHEXIT performs 
additional processing to remove the SVRB 
from the transient area queues. To do 
this, the TAHEXIT routine determines the 
address of the TACT entry for the transient 
area occupied by the exiting routine. This 
address is obtained by adding the displace- 
ment of the TACT entry (contained in the 
exiting SVRB) to the address of the tran- 
sient area control table (lEAQTAQ). (See 
Figure 9-1.) The TAHEXIT subroutine then 
searches the user queue associated with the 
TACT entry, looking for an SVRB which is 
"using" the exiting routine. (An SVRB is 
"using" the exiting routine if the TTR 
address in the SVRB is the same as the TTR 
address in the TACT entry.) 

When an SVRB that is using the exiting 
routine is found, the TAHEXIT subroutine 
checks if it is the SVRB that was control- 



Before branching to the TAHEXIT subrou- 
tine, the RB queue is searched for SVRBs. 
If none are found, the TCBATT flag is reset 
to zero. 



If the Returning Routine Is a user Program 

If the test of the RB type indicates a 
PRB, meaning that a user program is return- 
ing control, the Exit routine first moves 
the user's register contents from their 
save area in lower main storage, where they 
had been saved by the SVC FLIH, to the save 
area in the current TCB. This action is in 
preparation for the Dispatcher's restoring 
of registers just before it returns control 
to the caller's task. 

If the returning program is the last to 
be executed for its task, the Exit routine 
branches to the End-of-Task (EOT) routine 
to perform normal task termination. The 
Exit routine determines this condition by 
testing the RBTCBNXT flag of the PRB. This 
flag, if set, indicates that the RBLINK 
field points directly to the TCB. In this 
case, the PRB represents the last executed 
routine of its task. 

If the returning program is not the last 
to be executed for its task, the Exit rou- 
tine branches to the CDEXIT subroutine to 
determine if there are other requests for 
the use of the completed program, and to 
prepare for reentry to the program if there 
are such requests. The CDEXIT routine 
tests if the exiting program has a contents 
directory entry (CDE) ; the existence of a 
CDE is indicated in the CDE field of the 
PRB. If there is no CDE, the exiting pro- 
gram was entered via use of the SYNCH macro 
instruction, which does not build a CDE; in 
this case, the CDEXIT routine returns con- 
trol to the Exit routine. If there is a 
CDE, the CDEXIT routine continues 
processing. 



Section 9: Exiting Procedures 189 



User Queue 1 



Transient Area 
Fetch SVRB 



Legend 




= Pointer 



CZZZ/ - Information Fl 



NOTES: 1 . User queue 1 contains SVRBs whose SVC routine is in TAB 1, 
or was overlaid in TAB 1 . 

User queue 2 contains SVRBs whose SVC routine is in TAB 2, 
or was overlaid in TAB 2. 

2. The request queue contains SVRBs awaiting an available TAB 



Figure 9-1. The Transient Area Queues 
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The CDEXIT routine determines the type 
of CDE. There are two types of CDE — a 
major CDE, which is associated with the 
major entry-point of its program; and a 
minor CDE, which is associated with an 
alias or with an entry point set up by the 
execution of an IDENTIFY macro instruction. 
If the CDE pointed to by the PRB is a minor 
CDE, the CDEXIT routine finds the asso- 
ciated major CDE. It then reduces the use/ 
responsibility count in the major CDE. 



The use/responsibility count is the 
number of times the ATTACH, LINK, XCTL, or 
LOAD macro instructions have been issued 
for the module. It is used to keep track 
of the number of outstanding requests for a 
completed load module or program. 

If the exiting program is serially reus- 
able and there is at least one outstanding 
request for its use (indicated by a nonzero 
RBPGMQ field in the PRB) , the CDEXIT rou- 
tine updates the RB address in the CDE so 
it points to the next PRB that controls the 
program. This next PRB is associated with 
a task different from that of the caller. 
The address of the next PRB is obtained via 
the RBPGMQ field of the PRB. The CDEXIT 
routine makes the new PRB ready by placing 
zero in its wait count field; the Dispatch- 
er tests this field before dispatching the 
program. The CDEXIT routine also sets the 
right half of the old PSW field in the new 
PRB, in preparation for later entry to the 
Contents Supervision subroutine CDEPILOG. 

The CDEPILOG subroutine is executed when 
the Dispatcher recognizes the new PRB's 
task as the highest priority ready task. 
(The CDEPILOG subroutine performs final 
preparation for linkage to the requested 
program. ) 

After preparing the next PRB to control 
the program, the CDEXIT routine branches to 
the Task Switching routine. This routine 
tests whether the TCB for the previously 
waiting PRB may replace the current TCB. 
It does this by comparing dispatching 
priorities. If a task switch is needed, 
the Task Switching routine places the 
address of the new TCB in the "new" TCB 
pointer. This pointer is later tested by 
the Dispatcher. The Task Switching routine 
returns control to the CDEXIT routine, 
which in turn returns control to the Exit 
routine. 

If there are no other requests for the 
exiting program, the CDEXIT routine uses 
its subroutine, the CDHKEEP routine. The 
CDHKEEP routine sets the "non- functional" 
flag in the CDE to indicate that the pro- 
gram has been executed. Although this flag 
is meaningful only for nonreusable pro- 
grams, it is always set at this point in 
the processing. 



The CDHKEEP routine tests the use/ 
responsibility count in the CDE to deter- 
mine if there are other requests for the 
exiting program. (This test is necessary, 
since CDHKEEP can be invoked separately by 
other parts of the supervisor.) If the 
use/responsibility count is not zero, there 
is at least one outstanding request for the 
program, and CDHKEEP returns control to the 
Exit routine (or to CDHKEEP' s caller). If, 
however, the use/responsibility count is 
zero, there is no outstanding request for 
the program. In this case, the routine 
tests the program's attributes. If the 
program is in the link pack area, control 
is immediately returned to the caller, 
since the program must not be purged. If 
the program is not in the link pack area 
and is either serially reusable or reenter- 
able, the routine sets the "release" flag 
(CDATTR2 field) in the program's CDE and 
the "purge" flag^ for the job pack queue. 
These flags will be tested by the GETMAIN 
routine (CDPURGE subroutine) to determine 
which program's space should be freed, if 
space is requested and is otherwise 
unavailable. If the program is neither 
serially reusable nor reenterable, or was 
fetched^ by a job step that has invoked 
rollout, the CDHKEEP routine branches to 
another subroutine of CDEXIT, the CDDESTRY 
routine. The CDDESTRY routine frees the 
storage areas used by the program and cer- 
tain related control blocks. 

The CDDESTRY routine uses the extent 
list for the exiting program to set up 
input parameters to be passed to the FREE- 
MAIN routine. The extent list is a control 
block set up by routines of contents super- 
vision; it contains the length of the 
module (program) and its starting address, 
or the length and address of each separate- 
ly loaded control section of a module that 
was scatter loaded. After setting up the 
parameters, the CDDESTRY routine branches 
to the FREEMAIN routine, which then frees 
the storage space occupied by the exiting 
program. 

When control returns from the FREEMAIN 
routine, the CDDESTRY routine branches to 
the ORDERCDQ routine. This routine locates 
the contents directory queue on which the 
CDE resides, searches for the CDE, and 
dequeues the major CDE and any minor CDEs 
that may have been created for the program. 
Such dequeuing is necessary so that the job 
pack queue of the contents directory 
reflects the freeing of the space occupied 



^The "purge" flag is the high order bit of 
the TCBJPQ field of the current TCB. 

2if the program was fetched via the LOAD 
macro instruction, the CDHKEEP routine 
returns control to the caller, and does 
not branch to the CDDESTRY routine to 
purge the program. 
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by the program. The ORDERCDQ routine 
returns control to the CDDESTRY routine, 
which again branches to the FREEMAIN rou- 
tine to free the space occupied by the 
dequeued CDEs and their associated extent 
list. After this operation has been per- 
formed, the CDDESTRY routine returns con- 
trol to the Exit routine (or to CDDESTRY' s 
caller) . 

If the Returning Program is a User Exit 
Routine 

If the exiting program was controlled by 
an SIRS, special processing is not 
required; control passes to the IRB- 
handling portion of the Exit routine, then 
right back to a user program. If the pro- 
gram was controlled by an IRB, special pro- 
cessing is required. 

When the time sharing option is included 
in the system, the Exit routine checks for 
an attention IRB. If one is found, the 
following special processing is performed 
by subroutine IKJATTNX: 

• Start all subtasks via a branch entry 
to lEAQSETS. 

• If this is not an exit from ABEND or a 
STAE exit routine, use the terminal 
attention interruption element (TAIE) 
to set up registers and resume PSW. 

• Free the TAIE. 

The Exit routine checks whether the use 
count in the IRB is zero. The use count 
may indicate that the parent task has 
requested multiple use of the same end-of- 
task exit routine (ETXR) for different sub- 
tasks. If the use count is not zero, indi- 
cating an additional need for the exiting 
user routine, the Exit routine branches to 
the Transient Area Refresh routine. But if 
the use count is zero, indicating that the 
IRB is no longer needed, the Exit routine 
tests whether there is a register save area 
that the requester of the user Exit routine 
had originally reserved, that may now be 
freed for reuse. If there is such an area, 
which is indicated by a nonzero RBPPSAV 
field in the IRB, the Exit routine branches 
to the FREEMAIN routine to free it. When 
return is made from the FREEMAIN routine, 
the area occupied by the RB is freed. 

Common Processing 

Unless the Exit routine has branched to 
the dispatcher, control is passed from the 
RB- dependent processing to common Exit pro- 
cessing at label EDTNX. If the exiting 
program is represented by the last RB on 
the RB queue, the Exit routine removes the 
current TCB from the TCB queue because it 
is no longer needed. The Exit routine also 
sets the termination flag (TCBFE) which is 



later used by the Detach routine. This 
avoids an incorrect branch to ABTERM when 
the subtask is eventually detached. Exit 
then forces a task switch as described 
below. 

If the TCBSTPPR flag is set, indicating 
that a task is to be set nondispatchable 
when no longer executing a privileged pro- 
gram, the TCBATT flag is not set, and the 
task is not abnormally terminating. Exit 
clears the TCBSTPPR flag and begins a 
search of the RB queue. This search is 
terminated when an SVRB or an RB with a 
protection key of zero is found. If an 
attention RB is found or if the entire 
queue is searched without finding an atten- 
tion RB, the TCB is set nondispatchable and 
the stop flag in the TCB (set by the STATUS 
macro instruction) is set to zero. 

If the next RB on the queue has the wait 
bit on and the "new" pointer contains the 
address of the current TCB, "hew" is set to 
zero to force a task switch when Exit 
passes control to the dispatcher. The Exit 
routine then sets the RB for the exiting 
program inactive and removes it from the RB 
queue and frees, if possible, the RB area. 
If the exiting RB is an IRB with a problem 
program save area, the save area is also 
freed. The Exit routine then branches 
directly to the Transient Area Refresh 
routine. 



THE TRANSIENT AREA REFRESH ROUTINE 

The Transient Area (TA) Refresh routine 
is contained in the Transient Area Handler 
module at entry point IEAQTR02) . It deter- 
mines if it is necessary to reload an over- 
laid SVC routine in a transient area. If 
reloading (refreshing) is necessary, the 
routine initiates a task switch to the 
appropriate transient area fetch task to 
reload the needed routine. 

The TA Refresh routine first checks if 
there are any "user" SVRBs for the tran- 
sient areas by checking the user count for 
the transient area. If the count is zero, 
the TA Refresh routine branches to the Dis- 
patcher, since there are no users for any 
transient area. If the count is not zero, 
the TA Refresh routine searches the user 
queue associated with each entry of the 
transient area control table (TACT) . The 
routine searches for indication of a rou- 
tine that needs to be refreshed (see Figure 
9-1). 

If a flag in the TACT entry indicates 
that the associated transient area is in 
process of being loaded, the user queue for 
that TACT entry is not searched. Other- 
wise, the queue is searched for the highest 
priority "ready user" SVRB. A user SVRB is 
an SVRB that was created when the asso- 



192 



ciated SVC routine was requested. It is 
ready if it is the top RB on its RB queue 
and its TCB is not set nondispatchable. If 
a ready user SVRB is found, the TA Refresh 
routine checks if the associated routine is 
already in the transient area. If the TTR 
field in the SVRB is the same as that in 
the TACT entry, the routine is in the tran- 
sient area. If the routine is not in the 
area, the TA Refresh routine prepares to 
overlay the routine that is currently in 
the area. 

The TA Refresh routine saves the RB wait 
count of the current RB and sets a new wait 
count of *FF" (decimal 255) in each user 
SVRB. The routine readies the TA Fetch TCB 
pointed to by the TACT entry. It then 
branches to the Task Switching routine to 
prepare for a task switch to the TA Fetch 
task by the Dispatcher. The TA Fetch TCB 
controls the TA Fetch routine. (See "Load- 
ing the Routine" in "Fetching a Nonresident 
Routine from Auxiliary Storage" in Section 
2.) 

The TA Refresh routine then tests the 
next TACT entry. 

If no ready user SVRB is found for a 
transient area, either the transient area 
is free or all user SVRBs are waiting. The 
TA Refresh routine indicates that deferred 
requests can be removed from the request 
queue, and then checks the next TACT entry. 

When all TACT entries have been checked, 
the TA Refresh routine tests whether it has 
indicated that deferred requests can be 
removed. If they cannot, the routine 
branches to the Dispatcher. If they can, 
the routine removes all SVRBs on the re- 
quest queue, clears the wait count field in 
each SVRB, and invokes the Task Switching 
routine to determine if the associated task 
is of higher priority than the current 
task. If the selected task is of higher 
priority, the Task Switching routine indi- 
cates to the Dispatcher the need for a task 
switch, by placing in the "new" TCB pointer 
the address of the selected TCB. The TA 
Refresh routine then branches to the 
Dispatcher. 



DISPATCHING (PERFORMING THE ACTUAL RETURN 
OF CONTROL) 



The Dispatcher is entered via a branch 
at the end of most interruption processing 
sequences. It receives control from any of 
the following supervisor routines, depend- 
ing on the type of routine that is return- 
ing control and/or the type of processing 
that should next be performed: 

• Type-1 Exit routine, when a type-1 SVC 
routine has been completed and the need 
for a task switch has been indicated. 



Exit routine, when a user program-check 
routine has been completed. 



Transient Area Refresh routine, when 
the return is from any routine except a 
type-1 SVC routine, a user program- 
check routine, or the I/O Supervisor. 



• I/O First-Level Interruption Handler, 
when the return is from the I/O 
Supervisor. 

• External First-Level Interruption 
Handler, when an external interruption 
has been serviced. 

• Program Check First-Level Interruption 
Handler, when the multiprocessing fea- 
ture has been selected. 

• ABTERM, when entered from a type-1 SVC 
which was entered by a branch entry. 

• SVC Second-Level Interruption Handler, 
when a transient area fetch task is to 
be given control to load a transient 
SVC routine. 

• Transient Area Fetch routine, when a 
transient SVC routine has been loaded 
and no error has been detected by the 
Program Fetch routine. 

• ABENDll, when it has selected another 
terminating task whose resources are to 
be purged. 

• DARt, when the job-step region has been 
set nondispatchable. 

In MVT with Model 65 multiprocessing, 
the first operation of the Dispatcher is a 
test for external interruptions that have 
occurred during program check or I/O FLIH 
routines and have not been processed. If 
there are any (FLRETFLG is not equal to 
zero) , control is passed to the External 
FLIH routine. 

The main function of the Dispatcher is 
to determine the next task whose current 
routine is to be given control, and to pass 
control to that routine. 

Other functions of the Dispatcher are: 

• Completing the scheduling of user 
(asynchronous) exit routines. 

• Handling task and job-step timing. 

• Recognizing that a priority level is 
time-sliced, determining which task 
within the group to dispatch, and dis- 
patching the task for the maximum time 
interval (if time-slicing is included 
in the system) . 
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DETERMINING AND GIVING CONTROL TO THE 
CORRENT ROUTINE OF THE TASK NEXT TO BE 
DISPATCHED 

The Dispatcher decides the task next to 
be dispatched and passes control to the 
current routine of that task. The task 
next to be dispatched is one of the 
following : 

• The current task, whose performance is 
being resumed. 

• Another ready task of higher priority 
than the current task. 

• Another ready task of lower priority 
than the current task, if the current 
task is waiting or is nondispatchable. 

• Another task in the same time-sliced 
group (if time-slicing is included in 
the system) . 

The interrupted routine of the current 
task is given control if no supervisor rou- 
tine has indicated the need for a task 
switch. If, however, a task switch has 
been indicated, the Dispatcher gives con- 
trol to the current routine of the highest 
priority ready task. This task may be of 
higher or lower priority than the current 
task. The address of the "new" task's TCB 
is found either in the "new" TCB pointer 
(lEATCBP) , or through a search of the TCB 
queue. 

If the Dispatcher does not find a ready 
TCB whose current routine it may dispatch, 
it dispatches a special pseudo, or dummy, 
task which is part of the nucleus. The 
pseudo task has no associated routines, and 
places the CPU in an enabled wait state. 
After a future interruption, one of the 
nonready tasks may be readied by an inter- 
ruption handler, and CPU execution can 
continue. 

Normal Dispatcher Processing (Without 
Time-Slicing) 

The Dispatcher determines which task 
should be performed next: the current task 
or another ready task. It does this by 
comparing the contents of the "old" and 
"new" TCB pointers, IEATCBP+4 and lEATCBP. 
These locations are obtained via a pointer 
in the communications vector table, called 
CVTTCBP. They contain the addresses of the 
current ("old") TCB and the "new" TCB for 
the task next to be dispatched. 

If the two TCB pointers are equal, no 
supervisor routine has indicated the need 
for a task switch since the Dispatcher was 
last executed. The Dispatcher restores 
registers from the save area of the current 
TCB, and returns control to the interrupted 



routine by loading the RB old PSW from the 
routine's RB. 

If the two TCB pointers are not equal, a 
task switch is required. If the emulator 
option and the Model 85 were specified at 
system generation, the Dispatcher checks 
the TCB (bit 3 in the TCBTRN field) to see 
if the old task is the 7094 emulator pro- 
gram. If it is, the Dispatcher issues a 
Diagnose instruction to save emulator sta- 
tus and leave emulator mode. The Dispatch- 
er then saves the floating point register 
contents in the floating point register 
save area of the current TCB. The general 
register contents were previously saved in 
the current TCB by one of the following 
routines, depending on the linkage path to 
the Dispatcher: 

• Type-1 Exit Routine. 

• Exit routine. 

• Transient Area Exit routine. 

• ABTERM. 

• SVC Second-Level Interruption Handler. 

• External First-Level Interruption Han- 
dler. 

• I/O First-Level Interruption Handler. 

• ABENDll. 

• DAR4, 

The Dispatcher then determines the next 
task which receives control. 

If the two TCB pointers are not equal 
and the "new" TCB pointer (lEATCBP) does 
not contain zero, it points to the "new" 
TCB whose current routine is given control. 
This condition is usually the result of 
recognition by the Task Switching routine 
that a task higher in priority than the 
current task is ready. The Dispatcher 
restores registers, both general and float- 
ing point, from the "new" TCB. If the emu- 
lator option and the Model 85 were speci- 
fied at system generation, the Dispatcher 
checks the TCB (bit 3 in the TCBTRN field) 
to see if the new task is the 7094 emulator 
program. If it is, the Dispatcher issues a 
Diagnose instruction to restore emulator 
status and enter emulator mode. It then 
gives control to the new task's current 
routine by loading the RB old PSW from the 
task's current RB. (The TCBRBP field of 
the TCB points to the task's current RB.) 

In MVT with Model 65 multiprocessing, if 
the two TCB pointers are not equal, and the 
"new" TCB pointer does not contain zero, 
the Dispatcher searches down the TCB queue. 
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The search begins with the TCB whose 
address is in the "new" TCB pointer of the 
executing CPU. The address of the next 
highest priority ready task is placed in 
the "new" TCB pointer of the second CPU. 

If the two TCB pointers are unequal and 
the "new" TCB pointer contains zero, then 
the current task has been placed in a wait 
condition. In this case, the Dispatcher 
must determine the next highest priority 
ready task. The Dispatcher searches down 
the TCB queue, starting from the current 
TCB. It locates each successive TCB 
through the TCB link field (TCBTCB) . The 
current routine associated with the first 
TCB that meets the following conditions is 
given control, via a Load PSW instruction: 

1. The TCB's current RB must not be in 
wait condition (that is, the RBWCF 
field must contain zero) . 

2. The nondispatchability flags in the 
TCB must not be set (see Table 2 in 
"Termination Procedures", Section 10). 

In either of the two cases in which the 
two TCB pointers are not equal, the Dis- 
patcher sets both pointers equal to the 
address of the "hew" TCB. Thus, for future 
processing, the TCB pointers no longer in- 
dicate the need for a task switch. 

In MVT with Model 65 multiprocessing, if 
the two TCB pointers are unequal and the 
"new" TCB pointer for the executing TCB 
contains zero, the Dispatcher searches down 
the TCB queue to determine the two highest 
priority ready tasks. The search begins 
from the top of the queue when the "new" 
TCB pointer of both CPUs contains zero; 
otherwise, the Relative Priority routine 
determines whether the current TCB on the 
executing CPU, or the TCB whose address is 
in the "new" TCB pointer of the second CPU, 
is higher on the TCB queue, and the search 
begins from the higher TCB. The highest 
priority ready task that is not the current 
task on the second CPU becomes the new TCB 
on the executing CPU. If the highest 
priority ready task is not the current TCB 
on the second CPU and the "new" TCB pointer 
for that CPU is not set, the search con- 
tinues down the TCB queue for the next 
ready TCB. The address of this TCB is 
placed in the "new" TCB pointer of the 
second CPU. 

If the Dispatcher in its search of the 
TCB queue finds no ready task, it selects a 
special TCB that represents a pseudo task. 
The Dispatcher then loads the RB old PSW 
from the permanent RB that is part of the 
pseudo TCB. This RB old PSW, when loaded, 
places the CPU in an enabled wait state. 
After a future interruption, one of the 
nonready tasks may be made ready by an 



interruption handler, and CPU processing 
can continue. 

If the system includes the System Man- 
agement Facility (SMF) , the Dispatcher 
records the beginning of a system wait 
before loading the RB old PSW to dispatch 
the pseudo task. It reads the interval 
timer and stores its value in the first 
word of a special save area, SYSWSAVE. The 
value is later saved by the SMF Wait Time 
Collection routine and used to calculate 
elapsed wait time. 

In MVT with Model 65 multiprocessing, if 
the two TCB pointers of the second CPU are 
not equal (after the TCB queue has been 
searched) control is given to the SHOLDTAP 
routine which interrupts the second CPU 
with an indication (in STMASK) that the 
Dispatcher routine must gain control. 
Before dispatching the next task on the 
executing CPU, the old PSW is examined, 
and, if it is completely enabled, zeros are 
placed in the supervisor lock and CPU 
affinity bytes. An enabled old PSW indi- 
cates that the supervisor lock byte was not 
set by the task that is to be dispatched, 
and therefore the lock byte is cleared 
before this task receives control. 



Dispatcher Processing with Time-Slicing 
(Differences) 

When the "new" and "old" TCB pointers 
are equal, the Dispatcher tests whether 
"old" represents a time- si iced task. If it 
does not, normal dispatcher processing con- 
tinues . If it does the Dispatcher tests 
whether the time-slice interval has 
expired; it has expired if the time-slice 
TQE is off the timer queue. When this is 
the case, a task switch (to the next ready 
TCB in the time-slice group) is indicated, 
and the Dispatcher sets "new" to zero to 
force the task switch. If the interval has 
not expired, special processing is not 
required. 

When the "new" TCB pointer contains 
zero, it indicates the current task has 
been forced to wait and no higher-priority 
task is dispatchable. The Dispatcher again 
must test "old" for time-slicing; if it 
represents a time- sliced task, the next 
ready task in the time-slice group should 
be dispatched. 

When "new" contains an address not equal 
to the TCB address in "old," it indicates 
(1) a higher-priority task has become ready 
to be dispatched, or (2) another task in 
the same time-slice group has become ready. 
The Dispatcher tests to determine the case. 
If the task represented by "new" is in the 
same time-slice group as the one repre- 
sented by "old", the Dispatcher ignores the 
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requested task switch; the new task must 
wait its turn. 



When the next task to be dispatched is a 
time- sliced task (whether or not it is in 
the same time-slice group as the previous 
task) , the Dispatcher updates the TSCE 
pointers for the new task's group. The 
Dispatcher finds the next TCB in the time- 
slice group on the TCB queue and places its 
address in the Next field of the TSCE. It 
also enqueues the time-slice TQE. 



When time-slicing is included in the 
Model 65 Multiprocessing System, extensions 
to the logic of both MVT and MVT with Model 
65 multiprocessing must be made. A basic 
change to MVT time-slicing logic is needed 
so that two time-sliced tasks of either the 
same or different dispatching priorities 
can run simultaneously. The logic for MVT 
with Model 65 multiprocessing is changed in 
only one way — time-slicing logic is added. 
A fundamental modification of MVT with 
Model 65 multiprocessing logic is the 
restriction on the definition of the "hew" 
TCB pointers in terms of queue position in 
the following cases: 

1. If the highest-priority ready task is 
the only ready task of its TCB dis- 
patching priority (TCBDSP) , and the 
next highest- priority task is in a 
lower-priority time-slice group (TSG) , 
the next highest-priority task is not 
"new" on the second CPU if it is not 
the current, the next-to-run, or the 
only ready member of that TSG. 

2. If the two highest- priority tasks are 
members of the same TSG, both tasks 
become the two "new" tasks if they are 
the two current, the next-to-run mem- 
bers, or the only ready members of the 
TSG. 

These restrictions are important 
because, if either "hew" task on both CPUs 
is time-sliced but is not running currently 
or is not entitled to resume (does not 
satisfy the conditions that "new = old" and 
the TSTQE is on the queue) , that task is 
replaced by the next eligible task of the 
same TCBDSP. If both "new" TCB pointers 
are not current members of the same TSG, a 
search is made for the next two eligible 
tasks, the first of which becomes "newj." 
(unless it happens to be "olda", which 
indicates that the current task on the 
other CPU is entitled to resume) . 

The search loop for TCBDSPs considers 
the existence of "olda" (the current task 
on the other CPU) and the possibility that 
either "hew" may have been determined 
already. 



A shoulder-tap is issued if "newa = 
olda" but TSTQEa is off the queue (indicat- 
ing that the task on the other CPU has lost 
its turn) . No shoulder- tap is issued if 
"newa" and "dlda" are members of the same 
TSG, and TSTQEa is on the queue (indicating 
that "olda" is entitled to continue). In 
this case, "neWa" is set equal to "olda". 

TSO Processincf ; Prior to comparing the 
"new" and "old" pointers, the dispatcher 
passes control to the time sharing dis- 
patcher to re-order the ready queue if 
required. Control returns to the test of 
the "new" and "old" pointers. 

The time sharing dispatcher also 
receives control after a task switch has 
occurred so that the time sharing driver 
can provide its monitoring function with 
appropriate data. 



COMPLETING THE SCHEDULING OF USER EXIT 
ROUTINES 

A minor function of the Dispatcher is to 
ensure that user (asynchronous) exit rou- 
tines, partially scheduled by the Stage 2 
Exit Effector, are completely scheduled. 
The Dispatcher tests the stage 3 switch 
(lEAODSOl) to determine whether there is at 
least one queue element (interruption queue 
element or request queue element) on a user 
(asynchronous) exit queue. (The switch is 
set by the Stage 2 Exit Effector when it 
places a queue element on either of the 
exit queues.) If the stage 3 switch is 
set, the Dispatcher branches to its subrou- 
tine, the Stage 3 Exit Effector (IEA0EF03) , 
to complete the scheduling of the user exit 
routine(s). (See "Scheduling a User Exit 
Routine" in Section 3, Task Supervision.) 



HANDLING TASK AND JOB-STEP TIMING 

If a task switch is to occur, the Dis- 
patcher updates the timer queue, and if 
necessary, the timer itself. The purpose 
is to alter the timing of task intervals 
because a different task is about to con- 
trol the CPU. The processing is different 
for the two types of timing handled by the 
Dispatcher, task timing and job-step 
timing. 

Task timing is requested by a routine of 
a task, via an STIMER macro instruction 
that specifies the TASK operand. If a task 
switch is needed, the Dispatcher tests 
whether the current task has an unexpired 
task-type^ interval. If it has, the Dis- 



^The type of interval request is indicated 
in the TQEFLGS field of the task's timer 
queue element. 
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patcher stops the timing of the current 
("old") task's interval. If the ("new") 
task to be dispatched has requested the 
timing of a task-type interval, the Dis- 
patcher restarts the timing of the "new" 
task's interval. 



Job- step timing is requested by a job 
step's initiator, via an STIMER macro 
instruction that specifies the TASK 
operand. The Dispatcher handles job step 
timing if two conditions are met: a task 
switch is needed, and the job-step timing 
option was specified during system genera- 
tion. If these conditions are met, the 
Dispatcher suspends timing of the job step 
whose task has given up control and 
restarts timing of the job step whose task 
is next to be dispatched. 



Handling Task Timing 

If a task switch is needed, the Dis- 
patcher performs task timing. The need for 
a task switch is indicated by the inequali- 
ty of the two TCB pointers, lEATCBP and 
lEATCBP+U. (The address of these pointers 
is in the CVTTCBP field of the communica- 
tions vector table.) 



If the task that is relinquishing con- 
trol (the "old" or current task) requested 
task timing, the Dispatcher branches to the 
Timer Second-Level Interruption Handler 
(entry point lEAQTDOl) to stop the timing 
of the requested interval. The "old" task 
requested task timing if it has a timer 
queue element (TQE) and if a task-type 
request is indicated in its TQE. The task 
has a TQE if the TCBTME field of its TCB 
does not contain zero.*- 



The Timer Second-Level Interruption Han- 
dler tests whether the "old" task's TQE is 
on the timer queue. If the TQE is not on 
the queue, the "old" task's interval is not 
being timed, and the Timer Second- Level 
Interruption Handler (hereafter called the 
Timer SLIH) returns control to the Dis- 
patcher. If, however, the "old" task's TQE 
is on the timer queue, an interval is being 
timed for this task. In this case, the 
Timer SLIH determines the absolute time 
remaining in the requested interval, stores 



^The TCBTME field is set by the STIMER rou- 
tine when it services a "set timer" requ- 
est. It contains zero in any of the fol- 
lowing cases: no STIMER macro instruction 
has been issued for this task; or the 
TTIMER routine has serviced a TTIMER macro 
instruction for this task that specifies 
the CANCEL operand; or the task has been 
terminated, normally or abnormally. 



this time in the TQE for future use, and 
removes the TQE from the timer queue. If 
the removed TQE was at the top of the timer 
queue, the Timer SLIH updates the interval 
timer. It places the time of expiration 
(TOX) value of the new top TQE in both the 
interval timer and the six-hour pseudo 
clock. The Timer SLIH then returns control 
to the Dispatcher. 

If the "new" task to be given control 
requested interval timing, the Dispatcher 
branches to the Timer SLIH (entry point 
lEAQTEOO) to restart timing of the inter- 
val. The "new" task requested interval 
timing if it has a TQE, as indicated by a 
nonzero TCBTME field in its TCB. The Timer 
SLIH tests whether the TQE for the "new" 
task is on the timer queue. (The TQEFLGS 
field of the TQE indicates if the TQE is on 
the timer queue.) If it is, the requested 
time interval is already being timed. In 
this case, the Timer SLIH immediately 
returns control to the Dispatcher. If, 
however, the "hew" task's TQE is not on the 
timer queue, processing is needed to 
restart the timing of the requested 
interval. 

The Timer SLIH computes a new time of 
expiration (TOX) for the requested interval 
and places the recomputed TOX value in the 
"new" task's TQE. (See Section 6, "Timer 
Supervision" for information on the compu- 
tation of the TOX. ) If the recomputed TOX 
value is smaller than the current value in 
the interval timer, the Timer SLIH places 
the new value in the timer. It then places 
the TQE on the timer queue in the relative 
position that is appropriate for the new 
TOX value. (TQEs are ordered on the queue 
according to their relative times of 
expiration.) When the TQE is on the timer 
queue, timing of the "hew" task's requested 
interval is resumed. The Timer SLIH then 
returns control to the Dispatcher. 

Handling Job-Step Timing 

The Dispatcher performs the following 
main functions for job-step timing, if the 
need for a task switch is indicated, and if 
the job-step timing option was specified 
during system generation: 

• Removes from the timer queue the TQE 
for the initiator of the job step asso- 
ciated with the "old" task if the TQE 
is TASK type. 

• Places on the timer queue the TQE for 
the initiator of the job step asso- 
ciated with the "new" task to be dis- 
patched if the TQE is TASK type. If 
the TQE is REAL and off the timer 
queue, it must be converted to TASK 
type and placed on the timer queue. 
If the TQE is REAL and on the timer 
queue, it must be removed from the 
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queue, converted to a TASK TQE and 
placed on the queue. 

REMOVING FROM THE TIMER QUEUE THE TQE FOR 
THE INITIATOR OF THE JOB STEP ASSOCIATED 
WITH THE TASK WHICH HAS GIVEN UP CONTROL ; 
The Dispatcher must determine whether the 
"old" task was the dummy (pseudo) task. 
For the meaning of the dummy (pseudo) task, 
see "Normal Dispatcher Processing (Without 
Time Slicing"). It does this by comparing 
the "old" TCB address to the RB pointer 
(TCBRBP) in the "old" TCB. If they are 
equal the dummy task had previously been 
dispatched, and there is no TQE to be 
removed from the timer queue. If the "old" 
TCB was not the dummy task, the Dispatcher 
finds the address of the TCB for the 
initiator of the job step whose task has 
just given up control. It finds this 
initiator TCB by following the TCB pointers 
illustrated in Figure 9-2. The Dispatcher 
then determines if the step requested tim- 
ing by testing for the presence of a TQE 
pointer (TCBTME) in the initiator TCB. If 
the field is zero, the user has specified 
that job-step timing is not to be applied 
to this job and there is no TQE. If there 
is a TQE, the Dispatcher tests it for non- 
expired TASK type TQE. If the TQE is REAL, 
it should not be removed from the timer 
queue because it represents a 30-minute 
interval enqueued by WAIT and dequeued by 
POST. When the Dispatcher finds an unex- 
pired TASK type TQE as the initiator's TQE, 
it branches to the Timer Second-Level 
Interruption Handler (entry point lEAQTDOl) 
to suspend job-step timing for the "old" 
task. 



i-jtor TCB 




TCB for Task Next 
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Legend: 



Figure 9-2. 



Locating the Initiator TCB 
Associated with the Task Next 
to be Dispatched 



In MVT with Model 65 multiprocessing, 
when two tasks of the same job step are 
running simultaneously, the time-to- 
expiration value of the job is halved. 
Therefore, when job-step timing is sus- 
pended for a task, the Dispatcher must 
determine if the task on both CPUs belong 
to the same job step. If so, the Dispatch- 
er must double the time to expiration value 
of the job-step TQE to restore nonconcur- 
rent timing. The Dispatcher branches to a 
subroutine (entry point DJSOO) to obtain 
the address of the job step TQE for the 
task on the second CPU. If this is the 
same TQE scheduled for removal from the 
timer queue, because it is associated with 
the "old" task on the first CPU, the TQE is 
not removed, and the time-to-expiration 
value is doubled. 



PLACING ON THE TIMER QUEUE THE TQE FOR THE 
INITIATOR OF THE JOB STEP ASSOCIATED WITH 
THE TASK TO BE DISPATCHED ; The Dispatcher 
finds the address of the TCB for the 
initiator of the job step whose task is to 
be dispatched. It then determines whether 
job-step timing was suppressed by testing 
the pointer to the TQE in the initiator TCB 
(TCBTME). If the field contains zero, no 
job-step timing is done. If the field is 
non-zero, the Dispatcher examines the TQE 
type for a non-expired TASK TQE. If the 
TQE is this type, the Dispatcher branches 
to the Timer SLIH (entry point lEAQTEOO) to 
restart job-step timing for the task it is 
about to dispatch. If the TQE is REAL, it 
indicates that a user's asynchronous exit 
is to be given control and it should be 
job-step timed. Therefore, the Dispatcher 
branches to the Timer SLIH (entry point 
lEAQTDOl) to remove the element from the 
timer queue. Next, the dispatcher moves 
the job-step time remaining value from the 
saved field to the TQEVAL field, and 
changes the TQE type from REAL to TASK by 
setting to an off position the two low- 
order bits (bits 6 and 7) in the flag byte 
in the TQE (TQEFLGS) . The Dispatcher then 
branches to the Timer SLIH (entry point 
lEAQTEOO) to restart job step timing for 
the task it is about to dispatch. 

In MVT with Model 65 multiprocessing, 
the Dispatcher branches to a subroutine 
(entry point DJSOO) to obtain the address 
of the job step TQE for the task on the 
second CPU. If this is the TQE scheduled 
for placement on the timer queue, because 
the task to be dispatched on this CPU 
belongs to the same job step as the task on 
the other CPU, the time-to-expiration value 
of the TQE is halved. In this way, the 
execution time of the job step is the same 
as if two tasks were not running 
simultaneously . 
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SECTION 10: TERMINATION PROCEDURES 



Termination procedures free the 
resources and control blocks belonging to 
the terminating task. The freed resources 
include exclusively used programs in main 
storage, enqueued resource requests, unex- 
pired timer requests, incomplete operator 
communications, exclusively used data sets, 
and unshared subpools of main storage. The 
control blocks that are removed from their 
queues and freed include one or more: 



• Task control blocks (TCBs). 

• Request blocks (RBs) . 

• Interruption queue elements (IQEs). 

• Queue elements (QELs) . 

• Queue control blocks (QCBs). 

• Subpool queue elements (SPQEs). 

• Contents directory elements (CDEs). 

• Timer queue elements (TQEs). 

• The program interruption element (PIE) 
for the task, if one exists. 



There are two types of termination pro- 
cedures, normal and abnormal. Normal ter- 
mination occurs when a task is complete; 
that is, when the last program to be 
executed for the task has completed its 
execution. Abnormal termination occurs 
when some type of unrecoverable error, such 
as a machine check, I/O error, or program 
check, has taken place. The task must be 
terminated to prevent waste of system 
resources. 

Normal and abnormal termination differ 
in their scope of action. Normal termina- 
tion frees resources only for the completed 
task, not for its subtasks or higher level 
tasks. Abnormal termination allows two 
options, task and step termination. In 
task termination the resources of only the 
malfunctioning task and its incomplete sub- 
tasks are freed. This option permits a 
program belonging to a higher level task in 
the job step to decide whether to continue 
the job step. But in step termination the 
resources used for the entire job step are 
freed, and the Job Scheduler ignores later 
steps of the same job. A task termination 
of the job-step task, the highest level 
task in the job step, produces the seune 
result as a step termination. 



NORMAL TERMINATION (EOT ROUTINE) 

Normal task termination is performed by 
the End-of-Task (EOT) routine, which 
receives control from the Exit routine when 
it detects an end-of-task condition. The 
EOT routine is strictly an internal super- 
visor routine; that is, it does not receive 
control directly via an SVC. It frees the 
previously mentioned resources and their 
control blocks. If an event control block 
(ECB) had been specified when the terminat- 
ing task was attached, the EOT routine 
posts the ECB with a completion code for 
examination by a program belonging to the 
parent task. To allow other programs to 
continue execution, the EOT routine modi- 
fies the TCB pointer to ensure a task 
switch, and then branches to the Dispatcher 
to return control to the current routine of 
the highest priority ready task. 

The EOT routine releases resources no 
longer needed when a task is completed. 
Its functions include: 

• Purging the operator communication 
queues. 

• Closing data sets opened for the com- 
pleted task. 

• Releasing unexpired timer elements. 

• Releasing the program interruption ele- 
ment (PIE) , if one exists. 

• Freeing storage acquired for this task. 

• Releasing programs loaded for the task. 

• Removing the task's deferred rollout 
requests (if any) from the rollout 
request queue. 

• Dequeuing the TCB for the task from the 
TCB queue and (conditionally) from the 
subtask queue and freeing its space. 

• Ensuring that the need for a task 
switch has been indicated. 

Note ; If the time sharing option is 
included in the systan, terminal attention 
exit elements (TAXES) are purged for the 
terminating TCB. 

After performing these functions, the 
EOT routine returns control to the Exit 
routine to free the RB for the last 
executed program of the task. Then, via 
the Dispatcher, control is given to the 
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current program of the highest priority 
ready task. 



The EOT routine receives control, via a 
branch, from the Exit routine when it 
detects an end-of-task condition. The Exit 
routine recognizes that the PRE for an 
exiting user program points to its TCB 
instead of to another RB. (The RBTCBNXT 
status bit in the PRB, when set, indicates 
that the RBLINK field points to a TCB.) 

The first step of EOT processing is to 
check whether there are any subtasks of the 
completed task that have not been detached. 
All subtasks should have been previously 
removed for the completed task. If there 
is at least one subtask that has not been 
detached (as indicated in the TCB by the 
subtask pointer TCBLTC) , the EOT routine 
sets up an error code (hexadecimal 
80A03000). It then issues an ABEND macro 
instruction to produce supervisor linkage 
to the ABEND routine in order to abnormally 
terminate the completed task. 

If there are no remaining subtasks, the 
EOT routine stores in the task's TCB the 
completion code that is provided to its 
parent task in the return code register. 
The parent task examines the completion 
code to determine the status of its sub- 
task. (The status of the subtask is 
examined by the parent task only if the 
subtask was attached with either the ECB or 
the ETXR operand specified.) 

After storing the completion code, the 
EOT routine tests whether a program inter- 
ruption element (PIE) exists and should be 
freed. If a PIE exists, its address 
appears in the TCBPIE field of the TCB, 
placed there earlier when the SPIE routine 
created the program interruption element- 
If the PIE exists, the EOT routine makes 
its space available for reuse by branching 
to the FREEMAIN SVC routine to release the 
space. 

After freeing the PIE, or if no PIE 
existed for the task, the EOT routine 
branches to the Purge Timer subroutine. 
The subroutine's purpose is to test for and 
remove any remaining timer queue elements. 
Such an element represents a request for a 
timer interval that has not yet expired. 
If a timer element exists (queued from the 
TCBTME field of the TCB) , the subroutine 
cancels the timer request and frees, via 
the FREEMAIN routine, the space occupied by 
the timer queue element (TQE) and any asso- 
ciated problem- program register save area. 

If the terminating task is a time shar- 
ing task, the Purge Timer subroutine uses 
the Purge TAXE routine (lEAKJXP) to remove 
terminal attention exit elements. 



The EOT routine next tests for any seri- 
ally reusable resources that were enqueued 
and not later dequeued. If there is such a 
resource, the "enqueue" count (TCBQEL) in 
the TCB is not zero. (The enqueue count in 
the TCB is increased by the ENQ routine and 
decreased by the DEQ routine. The count is 
stored in the high-order byte of the TCBFSA 
field.) If the enqueue count indicates 
that a resource was not dequeued, the EOT 
routine sets up an error code (hexadecimal 
80D03000) , and issues an ABEND macro 
instruction to abnormally terminate the 
task. 



If the EOT routine was not entered from 
ABEND, a branch is made to the "WTOR Purge" 
routine (IEECVED2) . If the terminating 
task is not a time sharing task, IEECVED2 
removes from the buffer queue and the reply 
queue those elements that are associated 
with the completed task. The elements 
represent messages to the operator and the 
operator's replies. The "WTOR Purge" rou- 
tine issues a "voiding" message telling the 
operator to cancel outstanding replies. 

If the terminating task is a time shar- 
ing task that is not in main storage, the 
"WTOR Purge" routine does not purge the 
reply queue elements and write queue 
elements . 

To ensure that all data sets used for 
the task have been closed, the EOT routine 
next branches to the "close data sets" sub- 
routine. This subroutine checks the TCBDEB 
field of the TCB. If the field is not 
zero, it contains the address of a data 
extent block, or DEB. The subroutine uses 
the DEB to obtain the address of a data 
control block, or DCB, which it supplies as 
an input parameter to the Close routine of 
data management. The subroutine then 
issues a CLOSE macro instruction to gain 
supervisor linkage to the Close routine. 
As part of its processing, the Close rou- 
tine updates the DEB address in the TCBDEB 
field. The "close data sets" subroutine 
repeats the CLOSE macro instruction for 
each DEB on the queue. When the DEB chain 
has been exhausted, all data sets for the 
task have been closed. 

After each execution of the Close rou- 
tine, the "close data sets" subroutine 
checks for an error that might have 
occurred during execution of the Close rou- 
tine. It does this by noting whether the 
TCBDEB field has been updated. If the 
field has not been updated, the subroutine 
recognizes that incorrect DEB information 
has been supplied. The subroutine sets up 
an error code (hexadecimal 80C03000) and 
issues an ABEND macro instruction to 
abnormally terminate the task. 
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After closing data sets, a check is made 
to determine if the terminating task has a 
parent (originating) task which is abnorm- 
ally terminating. If the parent task is 
abnormally terminating, the ABEND bit 
(TCBFA) is on. Because the parent task 
purges both itself and any subtasks, there 
is no need to go to the EOT routine for the 
terminating task. Instead, the task is set 
nondispatchable, and the parent task con- 
tinues abnormal processing. 

If there is no error detected during the 
closing of data sets , and there is no ter- 
minating parent task, the EOT routine 
branches to the CDEXIT subroutine. The 
CDEXIT subroutine either frees the task " s 
last executed program, or schedules the 
program' s execution for a waiting request- 
er. (For a detailed discussion, see "If 
the Returning Routine Is a User Program" in 
Section 9, "Exiting Procedures.") 

The EOT routine next releases modules 
that were loaded for the task (via the LOAD 
macro instruction) and are no longer needed 
for other tasks. It does this by branching 
to the "release loaded programs" subroutine 
(lEAQABL) . 

This subroutine releases modules that 
were loaded for the task, via a LOAD macro 
instruction, but which were not released 
via a DELETE macro instruction. 

To determine the number of outstanding 
requests for each module, the "release 
loaded programs" subroutine examines, in 
turn, each load list element in the task's 
load list. Each load list element repre- 
sents a module that was loaded for the 
task, via a LOAD macro instruction. (The 
list origin of the load list is the TCBLLS 
field of the TCB.) To determine the number 
of outstanding requests for the module, the 
subroutine subtracts the responsibility 
count from the use/responsibility count. 
The responsibility count in the module's 
load list element records the number of 
load requests for the module. The use/ 
responsibility count in the module's con- 
tents directory entry records the total 
number of requests for the module. (Each 
load list element points to an associated 
contents directory entry. ) 

The "release loaded programs" subroutine 
then branches to subroutine CDHKEEP to test 
the number of outstanding requests for the 
module. If there is a least one outstand- 
ing request for the module, CDHKEEP immedi- 
ately returns control to the "release 
loaded programs" subroutine. If, however, 
there are no outstanding requests for the 
module, CDHKEEP either frees the module and 
its control blocks, or sets flags to inform 
Main Storage Supervision that space may be 
purged, depending on the attributes of the 



module. If a time sharing task is the 
requester, the program is freed uncondi- 
tionally. (For further details, see "If 
the Returning Routine Is a User Program" in 
Section 9, "Exiting Procedures.") 



On return from the CDHKEEP subroutine, 
the "release loaded programs" subroutine 
frees the load list element for the module 
just tested and perhaps freed. The process 
is repeated until all the load list ele- 
ments, and possibly their associated 
modules, have been freed. 

The EOT routine next branches to the 
"release main storage" subroutine 
(lEAQSPET) to release space that was 
obtained for the task via a macro instruc- 
tion. This subroutine performs an addi- 
tional function if the completed task is 
the job-step task (the highest level task 
in the job step) . The subroutine ensures 
that programs remaining in the job pack 
area are freed. Such programs are reen- 
trant or serially reusable programs that 
were used during the execution of the job 
step. Their release was previously 
invoked, but since they were still needed 
for other tasks of the job step, their 
storage space was not freed. 

For any terminating task, the "release 
main storage" subroutine frees unshared 
subpools of main storage allocated to the 
task. The stibpools are represented by sub- 
pool queue elements (SPQEs) , which have 
their list origin in the TCBMSS field of 
the TCB. The subroutine examines each SPQE 
on the main storage queue. If an SPQE 
represents a subpool not shared with anoth- 
er task, the subpool and the SPQE are 
freed, via a branch to the FREEMAIN SVC 
routine. The main storage queue is 
updated, and the next element is examined. 
If, however, an SPQE represents a shared 
subpool, that subpool cannot be freed. 
When all elements have been examined, sub- 
pool 253 (supervisor queue area) is expli- 
citly freed, since there is no SPQE for 
this subpool. As a minor additional func- 
tion, the subroutine frees space occupied 
by a parameter list created during the 
execution of the "close data sets" 
subroutine. 

If the completed task is the job-step 
task, any remaining modules in the job pack 
area must be freed. A check is made of the 
job pack area queue (whose list origin is 
the TCBJPQ field) to discover if there is 
at least one contents directory entry (CDE) 
on the queue. If there is at least one 
CDE, the "release main storage" subroutine 
branches to entry point CDDESTRY in the 
CDEXIT routine to free remaining modules, 
CDEs, and extent lists. (For further 
information, see "If the Returning Routine 
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Is a User Program" in Section 9, "Exiting 
Procedures . " ) 



After freeing unshared subpools of main 
storage, the EOT routine initiates the 
scheduling of an end-of-task exit routine 
(ETXR) , if one had been originally 
requested by the ETXR operand when the task 
was attached. If the use of the ETXR rou- 
tine had been requested, the Attach routine 
would have created an interruption recpiest 
block (IRB) and an interruption queue ele- 
ment (IQE). The IRB provides future con- 
trol of the ETXR routine and aids in its 
scheduling, while the IQE represents the 
queued request. In addition, the Attach 
routine would have placed the address of 
the IQE in the newly created TCB, and set 
the TCBFETXR flag in the TCBFLGS field to 
indicate the presence of the ETXR request. 
Now, during end-of-task processing, the EOT 
routine checks the TCBFETXR flag to learn 
whether the use of an ETXR routine had been 
requested when the task was attached. If 
the flag is set, the EOT routine initiates 
scheduling of the ETXR by passing the 
address of the IQE to the Stage 2 Exit Ef- 
fector. (See "Scheduling User Exit Rou- 
tines" in Section 3, "Task Supervision.") 
The Stage 2 Exit Effector places the IQE 
representing the ETXR request on a queue of 
requests for user exit routines. Later, 
during the execution of the Dispatcher, the 
Stage 3 Exit Effector completes the ETXR 
scheduling. It places the IQE on a queue 
of IQEs belonging to the IRB, and place the 
IRB as the "current" RB on the RB queue of 
the attaching task. The ETXR routine is 
thus scheduled as the next program to be 
executed for the parent of the terminating 
task. 



If the time sharing option is included 
in the system, the time sharing EOT is 
entered. If the logon task is terminating 
and the user is to be assigned to a new 
region, the logon flags in the TJB and 
TSCVT are set, the TSC relogon flag is set, 
the TSEVENT macro instruction is issued for 
logoff, and the TSC ECB is posted. If the 
logon task is terminating and the user is 
to be disconnected, the disconnect flags in 
the TJB and TSCVT are set, the TSC discon- 
nect flag is set, the TSEVENT macro 
instruction is issued for logoff, and the 
TSC ECB is posted. If the terminating task 
is not logon, the TCB is removed from the 
TCB queue and the terminal job block exten- 
sion (TJBX) is updated. 

The EOT routine, via its "dequeue TCB" 
subroutine, removes the TCB of the ter- 
minating task from the TCB queue. Since 
the current task is now terminated, its TCB 
must be removed from consideration by the 
Dispatcher. 



If the time-slicing feature is included 
in the system, the EOT routine tests the 
time-slice bit (TCBFTS) in the TCB. If it 
is not set, normal EOT processing con- 
tinues. If it is set, indicating that the 
terminating task is a member of a time- 
sliced group, the EOT routine locates the 
TSCE for the group. The address fields 
(First, Last, and Next) in the TSCE are 
compared to the address of the terminating 
TCB. 

• If none of the address fields match the 
TCB, the EOT routine turns off the 
time-slice bit and normal EOT process- 
ing continues. 

• If all of the address fields match the 
TCB, the EOT routine places zeros in 
them to indicate that the time-sliced 
group is without members. Normal EOT 
processing then continues. 

• If the First field matches, the EOT 
routine places the address of the next 
lower TCB on the TCB queue in First. 

• If the Next field matches and Last does 
not, the EOT routine places the address 
of the next lower TCB on the TCB queue 
in Next. 

• If the Last field matches, the address 
of the next higher TCB on the TCB queue 
is placed in Last, and the address of 
the First TCB is placed in Next. 

Normal EOT processing continues after 
each case. 

The EOT routine next sets two completion 
flags in the TCB: the "normal completion" 
flag (TCBFE) and the "nondispatchable com- 
pletion" flag (TCBFC) . The "normal comple- 
tion" flag is of significance only during 
completion of the job-step task. If the 
terminating task is the job- step task, the 
"normal completion" flag indicates to an 
initiator of the Job Scheduler that the job 
step has been normally terminated. The 
"nondispatchable completion" flag is tested 
by the Detach SVC routine to determine 
whether to remove the subtask TCB from the 
TCB queue, or to abnormally terminate the 
subtask. If this flag is not set, the 
Detach routine assumes that the subtask to 
be detached is incomplete, and therefore 
schedules it for abnormal termination. 

If the attaching routine of the parent 
task had specified an event control block 
(ECB) , the EOT routine must now post the 
normal completion of the subtask for 
examination by a routine of the parent 
task. If no ECB was specified, posting is 
bypassed. For any terminating task except 
the job-step task, the "EOT posting" sub- 
routine checks for an ECB address in the 
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TCBECB field of the current TCB. If an ECB 
address exists, the subroutine tests its 
validity by determining if the ECB contains 
a valid RB address. This is necessary, 
since the Post routine does not check the 
ECB address. The ECB resides in a user 
storage area and therefore is subject to 
alteration by a user program. If the job- 
step task is being terminated, the validity 
of the ECB address is not checked, since 
this ECB resides in system-protected 
storage and cannot be altered by a user 
program. Validity checking, performed by a 
check subroutine, consists of a series of 
tests that reasonably ensure that the spec- 
ified ECB address is valid and will not 
produce a program check during Post pro- 
cessing. The EOT routine branches to the 
Post SVC routine to place in the ECB of the 
parent task the completion code that was 
stored in the subtask TCB. 



ABNORMAL TERMIMATION 

Abnormal termination is implemented pri- 
marily by four supervisor routines: the 
ABTERM routine, the ABEND routine, the 
Damage Assessment Routine (DAR) , and the 
ABDUMP routine. 



The ABTERM routine schedules the execu- 
tion of the ABEND routine. It does this 
for system routines that detect an error 
but cannot themselves issue an ABEND macro 
instruction. The ABTERM routine ensures 
that, after redispatching, the first 
instruction to be executed for the defec- 
tive task is an SVC 13 (ABEND) instruction. 
Thus, the ABTERM routine indirectly issues 
an ABEND macro instruction for the task 
specified for termination. (See Figure 
10-1.) 



The EOT routine next determines whether 
to remove the TCB for the terminating task 
from its parent's subtask queue, and free 
the TCB's storage space. If neither an ECB 
nor an ETXR routine was specified when the 
task was attached, information in the sub- 
task's TCB is not needed by any program of 
the parent task. In this case, the "erase 
phase" subroutine removes the TCB from its 
parent task's subtask queue and frees its 
storage space. But if either an ETXR rou- 
tine or an ECB was specified when the task 
was attached, a program belonging to its 
parent task may later examine information 
in the terminating task' s TCB. In this 
case, the TCB and the pointers needed to 
gain access to it must be retained. The 
Detach SVC routine, later invoked for the 
parent task, removes the TCB from its 
parent's subtask queue and frees its space. 



The EOT routine next ensures that the 
need for a task switch is indicated. The 
routine sets the "new" TCB pointer 
(lEATCBP) equal to zero, as an indication 
to the Dispatcher that it must search down 
the TCB queue to find the highest priority 
ready task. Control is returned to the 
Exit routine to free the space occupied by 
the last RB of the terminating task. 



The Exit routine then branches to the 
Transient Area Refresh routine to "refresh" 
a transient area block that may have been 
overlaid by the terminating task. (See 
"The Transient Area Refresh Routine" in 
Section 9, "Exiting Procedures.") The Tran- 
sient Area Refresh routine branches to the 
Dispatcher which gives control to the cur- 
rent routine of the highest priority ready 
task. 



The ABEND routine frees resources for 
the terminating task and its incomplete 
subtasks. The resources include programs, 
main storage, data sets, queued requests 
for serially reusable resources, and the 
control blocks that implement the alloca- 
tion of these resources to the task- 

The ABEND routine, if the terminating 
task is the job-step task, frees the 
resources belonging to all tasks of the job 
step. The job-step task is terminated in 
any of the following cases: 

• The invoking ABEND macro instruction 
specifies the STEP option. 

• The operator has issued a CANCEL com- 
mand. 

• All tasks in the job step are in a 30- 
minute wait. 

• The job-step timer interval has ex- 
pired. 

• SYSOUT data exceeded the limit speci- 
fied by the OUTLIM parameter of the 
associated DD statement. 

• The Machine-Check Handler^ is unable to 
recover from, a machine check that 
occurs during the job step, but deter- 
mines that the failure is not 
permanent. 



*-The Machine-Check Handler is optional sys- 
tem generation programming support for the 
System/360 Model 65 (MCH/65), and standard 
programming support for the Model 65 Mul- 
tiprocessor, the Model 85 (MCH/85) , and 
the System/370 Models 145 (MCH/145) , 155 
(MCH/155), and 165 {MCH/165) . Refer to 
Section 2: "Interruption Handling." 
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Figure 10-1. Scheduling of the ABEND Rou- 
tine by the ABTERM Routine 



The Damage Assessment Routine (DAR) 
receives control from various ABEND 
modules. DAR attempts to write a dump of 
main storage, and reinstates, or initiates 
reinstatement of a failing task. DAR 
informs the operator if reinstatement is 
impossible so that the operator may halt 
system processing. 

The ABDUMP routine may be invoked by the 
ABEND routine as part of an abnormal ter- 
mination, or it may be invoked at any time 
to perform a dynamic dump for a normal 
task. When invoked by the ABEND routine, 
the ABDUMP routine displays programs and 
control blocks belonging to the terminating 
task, and control blocks belonging to the 
task's descendants and direct ancestors. 
The ABDUMP routine is always invoked via a 
SNAP macro instruction. 



SCHEDULING AN ABNORMAL TERMINATION (ABTERM) 



routine. It does this for the following 
types of callers: 

• First-level interruption handlers. 

• Type-1 SVC routines, which cannot issue 
an SVC instruction. 

• System routines that must terminate a 
task other than the current task. 

• The SERl System Environment Recording 
routine or the Machine-Check Handler. 

• The Program-Check First-Level Interrup- 
tion Handler. Since it has special 
requirements, it cannot branch to the 
ABTERM routine directly, but must enter 
via a preliminary routine called the 
ABTERM Prologue routine. This routine 
performs housekeeping functions for the 
ABTERM routine. 

In scheduling the execution of the ABEND 
routine, the ABTERM routine performs the 
following major functions: 

• Refreshes the CVT address. 

• Interrogates flags to decide if the 
specified task should be scheduled for 
ABEND processing and/or if its subtasks 
should be set nondispatchable. 

• Saves the address of the next execut- 
able instruction at the time of the 
last interruption (contained in either 
the SVC old PSW or in the RB old PSW of 
the current RB) for display by ABDUMP 
during ABEND processing. 

• Stores the completion code and dump 
option in the TCB of the terminating 
task, for use by the ABEND routine. 

• If the time sharing option is included 
in the system, a time sharing task in 
terminal I/O wait will be set 
dispatchable. 

• Schedules abnormal termination of the 
specified task by pointing either the 
RB old PSW of the current RB or the SVC 
old PSW to an SVC 13 (SVC ABEND) 
instruction, in the communication vec- 
tor table. Conditionally indicates to 
the Dispatcher that a task switch to 
the scheduled task is needed. 

• Sets nondispatchable incomplete sub- 
tasks of the terminating task, except 
for subtasks that are either being ter- 
minated or are in "must complete" 
status . 



The ABTERM routine is a disabled, seri- 
ally reusable, resident non-SVC routine. 
It schedules the execution of the ABEND 



• In a Model 65 Multiprocessing System, 
determines, through a branch to the 
Task Removal routine, whether the cur- 
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rent task on the second CPU has been 
set nondispatchable- If it has, the 
second CPU is interrupted with ein indi- 
cation (in STMASK) that the Dispatcher 
routine must gain control. 

• Returns control to an address specified 
by the caller. 

There are two entry points to the ABTERM 
routine: one (lEAOABOl) is for the SVC 
FLIH and IBM type-1 SVC routines; the other 
(lEAOABOO) is for all other system routines 
that wish to schedule an abnormal 
termination. 

For entry at lEAOABOl, the ABTERM rou- 
tine assumes that the address of the TCB to 
be scheduled for termination is contained 
in register H and the system completion 
code is contained in the low order 12 bits 
of register 1. The dump option flag is 
added to the completion code passed. The 
dump option flag indicates that ABEND must 
invoke the ABDUMP routine during ABEND 
processing. 

The ABTERM routine, when entered at 
lEAOABOO, first refreshes the CVT address 
in case it has been overlaid during prior 
processing. Then it saves the caller's 
register contents and obtains and validity 
checks the TCB address. If the TCB address 
is invalid (the TCB is not one of the TCBs 
on the priority queue) , control is passed 
to entry point DISMISS in the I/O FLIH. At 
DISMISS, the I/O original entry switch 
(lORGSW) is set to zero and a branch is 
made to the Dispatcher. 

If the TCB address is valid, the ABTERM 
routine interrogates flags to determine if 
the specified task should be scheduled for 
ABEND processing, and/or if its subtasks 
should be set nondispatchable. 

If the time sharing option is included 
in the system, a task that is nondispatch- 
able due to terminal I/O wait is set dis- 
patchable. Various combinations of ABTERM 
processing are possible, depending on the 
condition of the task specified for ter- 
mination. The following discussion 
describes each condition of the specified 
task and the resultant processing, as out- 
lined in Figure 10-2. 

Processing if Specified Task Has Already 
Been Terminated 

(See Figure 10-2, condition 1.) In this 
case, the ABTERM routine does not schedule 
entry to the ABEND routine, nor does it 
attempt to set subtasks nondispatchable. 
Instead, the ABTERM routine simply restores 
the caller's register contents, and returns 
control to the routine whose address the 
caller had placed in the return register. 



A terminating task can be specified for 
abnormal termination if an operator's 
CANCEL command or the expiration of a job- 
step timer interval occurs concurrently 
with the execution of the EOT routine or 
the ABEND routine for the task. 



Processing if the Task Has Already Been 
Scheduled for Abnormal Termination 

(See Figure 10-2, condition 2.) If the 
specified task has already been scheduled 
for abnormal termination but the ABEND rou- 
tine has not yet been entered, the ABTERM 
routine does not reschedule ABEND process- 
ing for the task. It conditionally sets 
incomplete subtasks nondispatchable to pre- 
vent their competing for system resources 
for the terminating parent task. This con- 
dition, wherein the task has been scheduled 
for abnormal termination but has not yet 
been terminated, can readily occur. The 
Dispatcher can allow other tasks to be per- 
formed after ABTERM processing, before it 
dispatches the ABEND routine for the given 
task. 

If the specified task has at least one 
subtask (TCBLTC is not equal to zero) , the 
ABTERM routine branches to its SETSUBS sub- 
routine to determine which subtasks should 
be set nondispatchable. 

The SETSUBS subroutine uses its SCANTREE 
subroutine to find each TCB that represents 
a subtask or descendant (subtask of a sub- 
task) of the specified task. (See Figure 
10-3.) For each such TCB that the SCANTREE 
subroutine finds, the SETSUBS subroutine 
tests if the associated subtask or descen- 
dant should be set nondispatchable. The 
tests are repeated for each subtask or 
descendant in the "subtask tree." 

A subtask or descendant is set nondis- 
patchable if none of the following condi- 
tions exists : 

• Subtask is complete (thus no need for 
setting the subtask nondispatchable) . 

• Subtask is in the process of abnormal 
termination (the ABEND routine is being 
executed for the subtask) . In this 
case, nondispatchability would prevent 
the further execution of the ABEND rou- 
tine for the subtask. 

• Specified task is nondispatchable, but 
its subtask is dispatchable. This sub- 
task may be in "must complete" status 
and should not be terminated or set 
nondispatchable. (For fvirther discus- 
sion of the "must complete" status, 
refer to "Serializing the Use of a 
Resource" in Section 3, "Task Supervi- 
sion.") 
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Conditions 



1. 



[ 

2. 



Specified task^ has already been termi- 
nated, normally or abnormally (TCBFC 
flag is set) . 



-T- 

I 



Resultant Processing 



No processing beyond the restoring of the 
caller's register contents and return of 
control to an address specified by the 
caller. 2 



Specified task has already been sched- 
uled for abnormal termination. 



ABTERM conditionally sets the incomplete 
subtasks of the specified task nondispatch- 
able. 



3. Specified task is the job-step task 
and is: 
a. Not already in the process 

of abnormal termination (TCBFA 

is not set) . 



b. Already being abnormally termi- 
nated, and the Initiator is not the 
caller. 



Prepares for scheduling of the termination 
by clearing nondispatchability flags 
(except "must complete" and "open in pro- 
cess" nondispatchability) in the specified 
task's TCB. Stores parameters (dump option 
flag and completion code) in the TCB. 
Saves old PSW and wait count (if applic- 
able) . schedules the task for entry to 
ABEND. Conditionally sets incomplete sub- 
tasks nondispatchable. 
_ _ 1 

Schedules the task for entry to ABEND. 
Conditionally sets incomplete subtasks non- 
dispatchable. 
_ _ __ ^ 



c. Already being abnormally termi- 
nated, and the Initiator is the 
caller and: 

(1) Dump option flag specifies a 
dump. 



ABTERM assumes that a CANCEL command has 
occurred or job-step timer has expired, 
concurrently with ABEND execution. The 
processing is the scime as in step 2. 



-H 



(2) No dump is specified. 



ABTERM assumes that a CANCEL command has 
been issued to stop a prolonged dump (pos- 
sible infinite loop) . Sets flags in the 
task's TCB to give the appearance of a 
first-time entry to ABEND. Remainder of 
processing is the same as in step 3a, 
except that parameters are not stored in 
the TCB and the old PSW and wait count are 
not saved during scheduling of the 
termination. 



ij. Specified task is not the job-step task 

and: 

a. Specified task was previously set 
nondispatchable by ABTERM or 
ABEND (TCBABWF is "set"). 



Same processing as in step 2. 



Specified task is not in the pro- 
cess of termination by ABEND. 



Same processing as in step 3a, except that 
nondispatchability flags, if previously 
set, are not cleared. 



Specified task is in the process of 
termination by ABEND. 



Same processing as in step 3b. 



I 

^The "specified" task is the one whose TCB address is passed by the caller to ABTERM. 

2A11 processing options include the processing performed under condition 1. 
I 

Figure 10-2. ABTERM Processing 
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/ ( ^ ) ^\ ^ '^ ^°^^ specified for TerminaMon 




Legend: 



D is Second Subtask of B 
("Descandent" of A) 



\ C is Firsf Subtask of B 
^■{"Descendant" of A) 



o- 



task 



-^-= a pointer 

->-= a possible sequence of subtask examination by the SCANTREE 
subroutine 



Figure 10-3. A Tree of Subtasks and a Pos- 
sible Sequence of Examination 



The task is already being abnormally 
terminated and the Initiator is the 
caller. 



THE TASK IS NOT ALREADY" IN THE PROCESS OF 
ABNORMAL TERMINATION ; (See Figure 10-2, 
condition 3a.) In this case, the ABTERM 
routine proceeds to schedule the task for 
abnormal termination. (The clear state of 
the TCBFA flag in the job- step TCB indi- 
cates that the job-step TCB is not being 
terminated.) The ABTERM routine schedules 
the termination by: 

• Ensuring that the task is dispatchable. 

• Storing parameters for use by the ABEND 
routine. 

• Scheduling the dispatching of the ABEND 
routine . 

• Conditionally setting incomplete sub- 
tasks of the specified task nondis- 
patchable. 

• Returning control to the preloaded 
return address. 



The SETSUBS subroutine sets a subtask 
nondispatchable by setting the TCBABWF flag 
in the TCBFLGS field of the subtask' s TCB. 
The subroutine also prevents the scheduling 
of asynchronous exits for the subtask. The 
Dispatcher tests the nondispatchability 
flags and does not dispatch any routine for 
the subtask, until the ABEND routine later 
clears the flags in preparation for ter- 
minating the subtask. 



Processing if the Specified Task is the Job 
Step Task 

(See Figure 10-2, condition 3.) A job- 
step task is a task attached by an Initia- 
tor of the job scheduler and is the highest 
level task within the family of tasks of a 
job step. The entry to the ABTERM routine 
may be the result of a direct branch from 
the Initiator because of either an opera- 
tor's CANCEL command or the expiration of 
the job-step timer interval. Another pos- 
sibility is that an error has occurred in a 
routine operating for the job- step task. 
The type of ABTERM processing depends on 
the particular condition of the task. Pro- 
cessing for each of the following condi- 
tions is discussed separately: 



The task is not already in the process 
of abnormal termination. 

The task is already being abnormally 
terminated and the Initiator is not the 
caller. 



The ABTERM routine ensures that the 
ABEND routine can be dispatched for the 
terminating task. It does this by clearing 
all nondispatchability flags in the termi- 
nating task' s TCB, except the "must com- 
plete" and "open in progress" nondispatch- 
ability flags (TCBSYS and TCBSTP) . The 
Dispatcher later examines all these flags 
to determine that they are clear before 
dispatching the ABEND routine as the "cur- 
rent" routine for the terminating task. 

Note: The nondispatchability flags are set 
by the supervisor for reasons such as: the 
resources of a task in the job step are 
being dumped by the ABDUMP routine, or the 
SERl routine is in progress, or another 
task is in "must complete" status. (For 
further information on the TCB nondispatch- 
ability flags, refer to Figure 10-4.) 

The ABTERM routine next stores in the 
specified task's TCB the parameters that 
are needed by the ABEND routine. These 
parameters consist of the dump option flag, 
if a dump has been requested, and the com- 
pletion code supplied by the caller. The 
parameters are stored in the "completion 
code" field of the TCB, called TCBCMP. The 
dump option flag, if set, later causes the 
ABEND routine to invoke the ABDOMP routine 
to display the programs and control blocks 
of the terminating task. The completion 
code is displayed during the dump as part 
of the TCB, and is made available to the 
parent task, via the ABEND routine. (The 
parent of the job- step task is the 
Initiator. ) 
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i Name of Flag j Offset of Flag in TCBJ 



h 



Meaning of Flag 



TCBNDUMP 



TCBSER 



TCBONDSP 



TCBFC 



TCBABWF 



TCBWFC 



TCBFRO 



TCBSYS 



TCBSTP 



TCBFCDl 



TCBNDISP 



32.0 



32.1 



32.5 



32.6 



33.0 



33.1 



33.2 



33.3 



33-4 



33.5 



33.6 



33.7 



This task is nondispatchable ^ile the resources 
of a task in this job step are being dumped. 

This task is nondispatchable while the SERl rou- 
tine is being executed for this task. 

This task is nondispatchable \diile VARY or QUIESCE 
processing is being performed in a multiprocessing 
system. 

This task is nondispatchable ^ile the Open rou- 
tine is being executed for another task as part of 
ABEND processing. 

This task is nondispatchable because it has been 
normally or abnormally terminated. 

This task is nondispatchable as part of a tree of 
tasks being abnormally terminated. 

This task is nondispatchable because it has issued 
an unconditional GETMAIN not yet satisfied by 
rollout. 

This task is nondispatchable because it has been 
rolled out. (Meaningful in all TCBs except system 
task TCBs.) 

This task is nondispatchable viiile another task in 
the system is in "system must complete" status. 

This task is nondispatchable while another task in 
the same job step is in "step must complete" 
status . 

This task is nondispatchable because it is an 
initiator task that is waiting for a requested 
region of main storage. 

This task is nondispatchable- See bytes 173, 174 
and 175 of the TCB for the cause. 



Figure 10-4- The TCB Nondispatchability Flags 



The ABTERM routine next schedules the 
dispatching of the ABEND routine for the 
specified task. In essence, the scheduling 
consists of: 



• Determining if the caller of the ABTERM 
routine is a type^l SVC routine. 

• Modifying the old PSW for the current 
routine so that it points to an SVC 13 
instruction in the communication vector 
table (CVT) . The old PSW iray be either 
the RB old PSW of the task's "top" RB, 
or the SVC old PSW in lower main 
storage (if the task's current routine 
has no SVRB) . 

• Removing an RB wait condition (if it 
exists) . 



• Permitting the Dispatcher, on a task 
priority basis, to cause execution of 
the SVC 13 instruction. 

When the SVC instruction is eventually 
executed, the SVC Second-Level Interruption 
Handler fetches the ABEND routine from 
auxiliary storage (if it is not already in 
a transient area of main storage) and 
passes control to it. The ABEND routine is 
controlled during its execution as a part 
of the terminating task. 

As a first step in the "scheduling" of 
the ABEND routine, the ABTERM routine 
determines which of two possible paths of 
processing will be followed. One path is 
used if the caller of the ABTERM routine is 
a type-1 SVC routine, and therefore is not 
controlled by an RB. The other path is 
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followed if the caller is not a type-1 SVC 
routine, and therefore is controlled by an 
BB. This discussion first considers the 
case in which the caller is not a type-1 
SVC routine, as determined by a test of the 
"type-1" switch, lEATYPEl. 

The caller is not a Type-l SVC Routine ; If 
the caller is not a type-1 SVC routine, the 
RB old PSW and the wait count to be altered 
are in the "top" or current RB for the 
specified task. (The current RB is the one 
pointed to directly by the TCB.) Before 
altering these fields, the ABTERM routine 
must first save the existing RB old PSW and 
the wait count, for display during ABDUMP 
processing. The second word of the RB old 
PSW, which contains the restart address, is 
saved in the RBABOPSW field of the current 
RB. For the same reason, the RB wait 
count, which the ABTERM routine clears, is 
also saved in the current RB. (If the cur- 
rent RB is an IRB, however, the wait count 
is not saved. ) The RB wait count is 
cleared to prepare for supervisor linkage 
to the ABEND routine. 

To permit the Dispatcher to place in 
execution an SVC- 13 instruction for the 
terminating task, the ABTERM routine 
branches to the supervisor's Task Switching 
routine- The ABTERM routine passes to the 
Task Switching routine the TCB address of 
the specified task. The Task Switching 
routine compares the dispatching priority 
of the task to be terminated with the dis- 
patching priority of the current task. If 
the task to be terminated is of higher 
priority than the current task, the Task 
Switching routine informs the Dispatcher by 
placing the higher priority TCB address in 
the "new" TCB pointer, lEATCBP. Without an 
alteration of the "new" TCB pointer, the 
Dispatcher would dispatch a routine belong- 
ing to either the current task or a lower- 
priority ready task. 

After control is returned from the Task 
Switching routine, the ABTERM routine com- 
pletes the scheduling of entry to the ABEND 
routine by pointing the previously men- 
tioned RB old PSW to the SVC-13 instruc- 
tion. It then sets the ABTERM flag 
(TCBABTRM) in the specified task's TCB, as 
an indication to both the ABTERM and ABEND 
routines that this task has been scheduled 
via the ABTERM routine. This indication, 
as described previously, limits ABTERM pro- 
cessing if a second branch to the ABTERM 
routine occurs for the same task. 

In addition, the routine sets the "pre- 
vent asynchronous exits" flag (TCBFX) in 
the specified task's TCB. Its purpose is 
to prevent the scheduling of a user exit 
routine for the task by the Stage 3 Exit 
Effector during Dispatcher processing, 
before entry to the ABEND routine occurs. 



The execution of a user exit routine would 
be a waste of CPU time for a task that is 
no longer productive, and is potentially 
harmful. Before returning control to the 
caller, the ABTERM routine conditionally 
sets incomplete subtasks of the specified 
task nondispatchable, as discussed in "Pro- 
cessing if the Task Has Already Been Sched- 
uled for Termination." 

The Caller is a Type-l SVC Routine ; If the 
caller has been a type-1 SVC routine, the 
processing is similar to the foregoing. 
Instead of saving and altering the RB old 
PSW in the "top" RB of the specified task, 
the ABTERM routine does the saving in the 
"top" RB and the altering in the SVC old 
PSW in lower main storage. This variation 
is necessary, since type-1 SVC routines do 
not operate under the control of an RB. In 
addition, the Task Switching routine is not 
invoked, since the caller's register con- 
tents are still in their lower main-storage 
save area (lEASCSAV), and may be lost by 
another SVC interruption following a task 
switch. 

THE TASK IS ALREADY BEING ABNORMALLY TER- 
MINATED AND THE INITATOR IS NOT THE CALLER ; 
(See Figure 10-2, condition 3b.) If the 
job step task is in the process of abnormal 
termination by the ABEND routine and the 
Initiator is not the caller, an attempt is 
being made to repeat an abnormal termina- 
tion for the same task. This means that an 
error condition has occurred during ABEND 
processing, which leads to a new request 
for abnormal termination of the task that 
is already being terminated. A new entry 
to the ABEND routine must be scheduled so 
that it can try, if possible, to complete 
termination procedures. Such a reentry to 
the ABEND routine for the same task is 
called a recursion. If the recursion is 
valid, the ABEND routine continues the ter- 
mination procedures. If, however, the 
recursion is invalid, the ABEND routine 
XCTLs to the Damage Assessment routine, 
which averts a CPU wait state by abnormally 
terminating only the failing task and its 
subtasks and by permitting the system to 
continue operating. 

Because the original ABEND parameters 
(completion code and the dump option flag) 
must be used by the ABEND routine, new 
parameters are ignored and are not placed 
in the specified TCB. The scheduling of 
the ABEND routine and the flagging of 
incomplete tasks as nondispatchable are 
performed, as described in the topic "The 
Task is Not Already in the Process of 
Abnormal Termination." Similar also is the 
return of control. There are, however, two 
differences. The old PSW and the RB wait 
count, if applicable, are not saved, since 
on a recursion to ABEND, a dump is not 
provided. 
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THE TASK IS ALREADY BEING ABNORMALLY TER- 
MINATED AND THE INITIATOR IS THE CALLER ; 
(See Figiire 10-2, condition 3c.) There are 
several possible causes of an ABEND request 
by the Initiator while the job-step task is 
already being abnormally terminated: 



• The job-step timer expired for this 
task. 



• The operator issued a CANCEL command 
for this task. 



• All tasks in the job step are in a 30- 
minute wait (completion code 522). 

• SYSOUT data exceeded the limit speci- 
fied by the OUTLIM parameter of the 
associated DO statement (completion 
code 722) . 

The processing varies, depending on 
whether a dump is specified. If a dump is 
specified, the ABTERM routine does not 
schedule entry to the ABEND routine, since 
the ABEND routine is already in execution 
to terminate the same task. It then re- 
stores registers and returns control to the 
caller. 

If a dump option is not specified, a 
CANCEL command was issued, probably to stop 
a prolonged dump that may be in an infinite 
loop. In this case (indicated by TCB 
flags) , entry to the ABEND routine is 
urgent. In order to stop the dump, the 
ABTERM routine gives the appearance of a 
first-time request for termination, this 
time with a dump not requested. 

The ABTERM routine gives the appearance 
of a first-time request for termination by 
clearing those flags in the TCB of the ter- 
minating task that indicate ABEND process- 
ing. After clearing the flags, the ABTERM 
routine clears all nondispatchability 
flags, except the "must complete", "open in 
progress", and Recovery Management Support 
(RMS) nondispatchability flags, that may be 
set in the job- step TCB. The purpose is to 
force the dispatching of ABEND for the job- 
step task to end the prolonged dump. The 
ABTERM routine does not save the RB old PSW 
and the wait count of the current RB, since 
the new termination request will not cause 
a dump. 

The remainder of ABTEI^ processing is 
similar to that previously described: the 
Task Switching routine is invoked, the 
ABEND routine is scheduled (RB old PSW and 
wait count are altered) , the ABTERM flag 
and the "prohibit asynchronous exits" flag 
are set, and control is returned as speci- 
fied by the caller. 



Processing if the Specified Task Is Not the 
Job Step Task 

If the task specified for abnormal ter- 
mination is not the job-step task, as indi- 
cated by the TCBJSTCB field in its TCB, 
there are three possible paths of process- 
ing . The path taken depends on whether the 
specified task had been previously set non- 
dispatchable by either the ABTERM or ABEND 
routine , and on whether the branch to the 
ABTERM routine represents an attempted 
recursion. The following discussion will 
consider each case separately. 

THE TASK WAS PREVIOUSLY SET NONDISPATCHABLE 
BY ABTERM OR ABEND : (See Figure 10-2, con- 
dition 4a.) In this case, entry to the 
ABEND routine is not scheduled. The reason 
is that an ancestor of the specified task 
is already in the process of abnormal ter- 
mination. There is no need for an explicit 
request for termination of the specified 
task, since its resources will be released 
as part of the termination of its ancestor. 

The processing for this condition con- 
sists of setting subtasks of the specified 
task nondispatchable (TCBABWF flag set) , if 
they were not all previously placed in this 
condition. This prevents any use of system 
resources by a subtask of the terminating 
task. Possibly during a previous entry to 
the ABTERM routine, a subtask was not set 
nondispatchable because it was in "must 
complete" status. If a routine of the sub- 
task has reset the "must complete" status, 
the subtask can now be set nondispatchable. 
The ABTERM routine then restores the cal- 
ler's register contents from the TCB, and 
returns control to an address the caller 
specified. 

THE TASK IS NOT IN THE PROCESS OF TERMINA- 
TION BY ABEND ; (See Figure 10-2, condition 
Ub. ) For this condition (indicated by the 
clear state of the TCBFA flag) , the pro- 
cessing is similar to that performed if the 
caller specified the job-step task. The 
only difference is that in this case the 
ABTERM routine does not clear nondispatch- 
ability flags in the TCB of the specified 
task. These flags must be cleared by the 
routine that set them, before the ABEND 
routine can be executed for the task. 

THE TASK IS IN THE PROCESS OF TERMINATION 
BY ABEND : (See Figure 10-2, condition Uc.) 
In this case, it is necessary to schedule 
reentry to the ABEND routine to test for 
valid recursion. 

Preparation for ABTERM Processing after a 
Program Interruption (ABTERM Prologue) 

After a program interruption, the 
Program-Check First Level Interruption 
Handler (PC FLIH) cannot branch directly to 
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the main entry point of the ABTERM routine 
(lEAOABOO) . First, certain housekeeping 
functions needed by the ABTERM routine must 
be performed. These functions are per- 
formed by a routine of ABTERM, called the 
ABTERM Prologue routine. 



Note ; If a program check occurs in a user 
program, the Program Check FLIH does not 
branch to the ABTERM Prologue routine if 
both of the following conditions exist: 

• A program interruption element (PIE) 
has been specified, and 

• The program interruption control area 
(PICA) specifies this particular inter- 
ruption type to be handled by a user 
routine. 

The ABTERM Prologue routine performs six 
main functions: 

• Refreshes the CVT address. 

• obtains the TCB address of the task to 
be terndnated and places it in a param- 
eter register for use by the ABTERM 
routine. 

• Sets up a completion code (system error 
code) that indicates the type of pro- 
gram check and places the error code in 
a parameter register for initial use by 
the ABTERM routine and ultimate use by 
the ABEND routine. 

• Conditionally saves the program- 
interruption old PSW for later display 
by the ABDUMP routine. 

• Places the address of the Dispatcher in 
the return register. 

• Sets up the dump option flag as an 
indication to the ABEND routine that it 
should invoke the ABDUMP SVC routine. 

The ABTERM Prologue routine (hereafter 
called the Prologue routine) first 
refreshes the CVT address at absolute loca- 
tion 16 (decimal) in case it has been over- 
laid during prior processing. Then it gets 
the current TCB address. The TCB address 
specifies the task to be scheduled for 
abnormal termination. If the program check 
occurred in the I/O Supervisor, as indi- 
cated by the "set" condition of the "I/O 
original interruption" switch (lORGSW), or 
if the program check occurred in SVC 
(EXCP) or in SVC 15 (ERREXCP), the Prologue 
routine passes control to the lOS Program 
Interruption Handler routine (lECCPLOO). 
If the program check did not occur in the 
I/O Supervisor or in SVC or SVC 15, the 
Prologue routine obtains the TCB address 
from the "current" TCB pointer (IEATCBP+4). 



After the determination of the TCB 
address, there are two streams of process- 
ing, depending on the source of the program 
check: a system or user program, or a 
type-1 SVC routine (or the SVC FLIH) . The 
source of the program check is determined 
by a test of the "type-1" switch. This 
discussion will first consider the path 
followed if the program check occurred in a 
routine of a system or user program. 

The first stream of processing is for a 
system routine (except a type-1 SVC rou- 
tine) or for a user program. The Prologue 
routine saves the registers and the address 
of the next executable instruction of the 
interrupted routine. This information is 
displayed during the dump that later occurs 
as part of ABEND processing. The Prologue 
routine saves the address of the instmic- 
tion by storing the program interruption 
old PSW in the RB old PSW field of the cur- 
rent RB. This RB is the "top" RB on the RB 
queue for the current TCB. The old PSW, so 
saved, cannot be lost by a new program 
check occurring before the original infor- 
mation can be displayed by ABDUMP. The 
register contents belonging to the inter- 
rupted program are moved from the program- 
interruption save area in lower main 
storage to the register save area of the 
current TCB (TCBGRS field) . They are even- 
tually placed in the ABEND routine's SVRB. 

The Prologue routine next sets up a com- 
pletion code (system error code) and a 
return address for later use by the ABTERM 
routine. The completion code indicates the 
type of interruption and suggests the 
source of the error, for example, 0c6 = 
specification error- (See the publication 
Messages and Codes . ) The ABTERM routine 
stores the completion code in the TCB for 
the task to be terminated. It then places 
in the return register the address of the 
Dispatcher, to which the ABTERM routine 
returns control when its processing is 
complete. 

If the program check has occurred in a 
type-1 SVC routine other the SVC or SVC 
15 (or in the SVC First-Level Interruption 
Handler) , as indicated by the "type-1" 
switch (lEATYPEl), the Prologue routine 
sets up a completion code and a return 
address for use by the ABTERM routine. 
This processing is similar to that pre- 
viously described, except that the error 
code is 0F2, indicating that a program 
check occurred in a type-1 SVC routine (or 
in the SVC FLIH) . The purpose is still the 
same: to indicate to the programmer, via a 
later dump, the type of program in which 
the error occurred. The ABTERM routine 
stores the completion code in the TCB 
belonging to the task to be terminated. 
After setting the completion code, the Pro- 
logue routine places in a register the 
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address of the Type-1 Exit routine, to 
which the ABTERM routine returns control. 

Regardless of the source of the program 
check, the Prologue routine sets the dump 
option flag and places the flag and the 
completion code in the parameter register. 
The dump option flag causes the ABEND rou- 
tine to invoke the ABDUMP SVC routine. The 
position of the completion code in the pa- 
rameter register indicates to the ABDUMP 
routine whether a system error or a user 
error has occurred (see Figure 10-5). 

The Prologue routine next branches to 
the main entry point of the ABTERM routine 
(lEAOABOO). 



DUMPING SELECTED AREAS OF MAIN STORAGE 
(ABDUMP) 

ABDUMP is an SVC routine which may be 
invoked through issuance of a SNAP macro 
instruction, either by the ABEND routine 
during an abnormal termination, or at any 
time by a user program. It can therefore 
provide an abnormal dump or a dynamic dump. 
If it is invoked by the ABEND routine, it 
displays major control blocks belonging to 
the terminating task, its subtasks, and its 
direct ancestors, and dynamically acquired 
storage and programs belonging to the ter- 
minating task. 

In systems with Main Storage Hierarchy 
Support, ABDUMP dumps main storage in each 
hierarchy associated with the terminating 
job step. Storage limits are determined by 
examining the PQE chain. 

The SNAP macro instruction (whose expan- 
sion contains an SVC 51 instruction) causes 
the SVC Second-Level Interruption Handler 
(SLIH) to search for and fetch the first 
load of SVC DUMP. Only those modules of 
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Format of the Completion Code 
and the Dump Option Flag in 
the Parameter Register 



the dump routines whose functions are 
requested are then fetched and executed. 



The ABDUMP routine consists of nonresi- 
dent modules that are separately fetched 
and executed, and one "resident" module 
that remains in main storage for the entire 
dump procedure. The multiprocessing ABDUMP 
routine includes one additional nonresident 
module. The resident module (lEAQADOA), 
loaded by the first segment of the ABDUMP 
routine, contains several format and output 
subroutines used by the other modules. The 
ABDUMP routine provides either a formatted 
printed display, or a series of blocked 
records on tape or on a direct access 
medium, such as disk. In either case, the 
output consists of a group of control 
blocks, followed by the prograirs and/or 
dynamically acquired storage of the task, 
depending on the areas requested. 

The first module, SVC DUMP 1, determines 
if an SDDMP macro instruction had been 
issued. If not, control is passed to 
ABDUMP 1. Otherwise, SVC DUMP 1 sets all 
non-system tasks nondispatchable, obtains 
the date and time of day and places these 
in the header record, and performs the dump 
to a direct access device. If the dump 
data set resides on a tape device, control 
is passed to SVC DUMP 2 to perform the 
dump. After the selected areas are dumped, 
SVC DUMP sets all tasks dispatchable and 
issues an SVC 3 instruction. 

ABDUMPl ensures that a dump data set has 
been opened for BSAM, provides a work area 
for use by the entire routine, loads the 
so-called "resident" module (format and 
output routines), and conditionally gets 
storage space for preserving the trace 
table and blocking the records. 

ABDUMP 1.5 displays the identification 
code (if specified) , job name, step name, 
time, and date. If the ABEND routine is 
the caller, ABDUMP 1.5 displays the comple- 
tion code from the specified task's TCB. 
If the old FSW is recpiested as an operand 
of the SNAP macro instruction, it is also 
displayed. 

ABDUMP2 formats and displays the old 
PSW, if requested, the TCB for the speci- 
fied task, the request blocks on its RB 
queue, and the load list for the task. 
Optionally, it displays the TCB register 
save area. 

ABDUMP3 formats and displays contents 
directory entries, and their extent lists 
(one for each major CDE) . 

ABDUMPQ formats and displays data extent 
blocks (DEBS) and the task I/O table 
(TIOT) . 
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ABDUMP4 identifies, formats, and dis- 
plays the control blocks of main storage 
supervision: subpool queue elements 
(SPQEs), descriptor queue elements (DQEs) , 
free queue elements (FQEs), the dummy par- 
tition queue element, the partition queue 
elements (PQEs), and the free block queue 
elements (FBQEs) . 



ABDUMP5 formats and displays the control 
blocks that schedule serially reusable 
resources — queue control blocks (QCBs) 
and queue elements (QELs) — and register 
save areas belonging to interruption re- 
quest blocks (IRBs). 

ABDUMP6 formats and displays the regis- 
ter save areas for each user program of the 
task. For each save area the following 
information is displayed: the address of 
the save area, the contents of the save 
area, the type of linkage (LINK or CALL) , 
the entry point identification, and a 
"call" identification (if the CALL macro 
instruction was used to obtain linkage) . 

If the dump request is for TCAM or a 
time sharing task, TCAM ABDUMP 1-H for TCAM 
or ABDUMP H-I for a time sharing task are 
processed next. 

ABDUMP7 formats and displays the nucleus 
of main storage, the register contents of 
the user program at entiry to ABDUMP, and 
dynamically acquired storage (if STORAGE is 
a keyword operand included with the SNAP 
macro instruction) . 

ABDUMP8 formats and displays load 
modules represented by contents directory 
entries. Each module fetched to main 
storage for the terminating or requesting 
task is displayed. 

ABDUMP9 formats and displays storage 
obtained dynamically by user programs 
within the task. Each block of main 
storage is identified by a search of the 
subpool queue element (SPQE) queue. 

ABDUMPll, executed in a multiprocessing 
system, displays the prefixed storage area 
in the nucleus. If the multi-system mode 
is operating, the prefixed storage area at 
upper main storage is also displayed. 

ABDUMP12, executed only in a uniproces- 
sing system, formats and displays the GTF 
trace data if GTF is active, and if the 
internal storage and formatting options 
were selected. If GTF tracing is dis- 
played, the optional supervisor trace table 
display is bypassed. 

ABDUMP13, executed only in a multi- 
processing system, performs the same func- 
tions as ABDUMP12. 



ABDUMP14 formats and displays GTF con- 
trol and error records. ABDUMP14 receives 
control from, and returns control to 
ABDUMP12 (ABDUMP13 in a multiprocessing 
system) . 

ABDUMP15, executed only in a uniproces- 
sing system, formats and displays the 
optional supervisor trace table if 
requested. 

ABDUMP16, executed only in a multi- 
processing system, formats and displays the 
optional supervisor trace table if 
requested. 

ABDUMPH formats and displays the pro- 
tected storage control block (PSCB) , the 
user profile table (UPT) , and the data set 
extension (DSE) for a dump request of a 
time sharing task. 

ABDUMPI formats and displays the termin- 
al job block (TJB) and the terminal job 
block extension (TJBX) for a dump request 
of a time sharing task. 

TCAM ABDUMPI formats and prints the 
header line, address vector table (AVT) , 
and the basic section of the terminal name 
table (TNT) for Telecommunications Access 
Method (TCAM) Message Control Programs 
(MCPs) . 

TCAM ABDUMP2 dumps the entries in the 
TNT and their associated terminal table 
(TRM) entries. 

TCAM ABDUMP3 dumps the TCAM destination 
queue control blocks associated with the 
TRM entries. 

TCAM ABDUMPt dumps open TCAM DCBs and 
the line control blocks associated with 
each line group DCB. 

Processing during ABDUMPI 
(Entry Point IGC0L05A) 

After having been fetched by the first 
load of SVC DUMP, ABDUMPI first tests two 
input parameters: the DCB for the dump 
data set, and the TCB for the task whose 
resources are to be displayed. (See Sec- 
tion 12, "Control Blocks and Tables," for 
the content and format of the ABDUMP para- 
meter list.) The DCB is associated with 
the data set on which the dump will appear. 
The caller — either the ABEND routine or a 
user program — must previously have opened 
the DCB for the dump data set. If the DCB 
has not been opened, ABDUMPI sets up an 
error return code (4) and, via the Exit 
routine and the Dispatcher, returns control 
to the caller. Otherwise, processing con- 
tinues. If a TCB address is provided as an 
input parameter, the resources of a task 
other than the current task are to be 
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dumped. To avoid a program check, ABDUMPl 
checks the validity of the TCB address. If 
the address is invalid, the routine sets up 
an error code (8) , and returns control to 
the caller, via the Exit routine and the 
Dispatcher. If the test suggests a valid 
TCB address, processing continues. 

If the task whose resources are to be 
dumped is not the current task (as indi- 
cated by the TCB address) , ABDUMPl sets all 
tasks of the job step nondispatchable 
except the current task. It does this to 
prevent concurrent dump requests issued by 
programs belonging to different tasks of 
the same job step from causing a possible 
"interlock" if one of the tasks abnormally 
terminates- Later, during ABDUMP9, when 
dynamically acquired storage has been dis- 
played, the tasks will again be set dis- 
patchable. If the multiprocessing feature 
was selected, control is passed to the Task 
Removal subroutine, which determines wheth- 
er the current task on the second CPU has 
been set nondispatchable. If it has, the 
second CPU is interrupted with an indica- 
tion (in STMASK) that the Dispatcher must 
gain control. 

To provide a work area for use by all 
load modules of the ABDUMP routine, ABDUMPl 
next obtains storage space. This area is 
later used to save registers, to serve as 
an output buffer and as a work area, and to 
hold pointers and flags. Later, after 
ABDUMP9, the Where-to-Go routine of the 
"resident" module frees the space obtained 
by ABDUMPl. 

ABDUMPl, via a LOAD macro instruction, 
next causes the fetching of the "resident" 
module of the ABDUMP routine (IGCOAOSA) to 
the job-step's region of main storage. If 
the "resident" module is resident in the 
link pack area, its execution is scheduled 
by the common subroutines of Contents 
Supervision. This module consists of for- 
mat and output routines that are used dur- 
ing the entire dump. Included are three 
format routines, an Output routine, a 
Where-to-Go routine, and a "TCB selection" 
routine. 

One format routine determines the posi- 
tion a labeled field occupies on a print 
line. Another format routine determines 
the number of 32-byte lines of print needed 
to format a block of storage, and the num- 
ber of bytes to be placed in the last 
incomplete print line. The third format 
routine unpacks a block of main storage and 
formats it in 4-byte fields in preparation 
for printout. 

The Output routine issues the WRITE and 
CHECK macro instructions to print a line on 
a printer or write a block of storage on 
tape or a direct access device. 



The Where-to-Go routine tests the flags 
in the input parameter list to determine 
which of several possible transient load 
modules of the ABDUMP routine should next 
receive control, after a given module's 
processing is complete. It also performs 
final housekeeping before control is 
returned to the caller of the ABDUMP 
routine. 



The "TCB selection" routine permits cer- 
tain modules of the ABDUMP routine to scan 
the TCBs of the job step in order to set 
the tasks nondispatchable or dispatchable. 
It is necessary to set tasks other than the 
current task nondispatchable. This pre- 
vents routines for other tasks from alter- 
ing control blocks while the blocks are 
being displayed. If the multiprocessing 
feature was selected, control is passed to 
the Task Removal subroutine, which deter- 
mines whether the current task on the 
second CPU has been set nondispatchable. 
If it has, the second CPU is interrupted 
with an indication (in STMASK) that the 
Dispatcher must gain control. After load- 
ing the resident module, if entry is not 
from the ABEND routine, ABDUMPl determines 
if GTF is active and if the GTF trace data 
is to be formatted. If these conditions 
are met, GTF tracing is suspended to ensure 
the validity of the GTF trace data. 
ABDUMPl then issues an ENQ macro instruc- 
tion for the dump data set. (The ABEND 
routine suspends GTF tracing and issues its 
own ENQ macro instruction for the dump data 
set.) It does this to prevent a program 
belonging to a task in the same job step 
from concurrently causing a new dump to the 
same data set. This could occur during a 
period of dispatchability, before the cur- 
rent dump is complete. 

If GTF is active, processing for the 
optional supervisor trace table is 
bypassed. However, if GTF is inactive, and 
if a display of the trace table was 
requested as an option of the SNAP macro 
instruction, ABDUMPl issues a conditional 
GETMAIN macro instruction for space so that 
it can move the contents of the table. The 
purpose is to prevent the table's further 
alteration during the ABDUMP and ABEND rou- 
tines. If the table is moved, ABDUMPl sets 
an indicator for ABDUMP15. If no space is 
available to which the trace table can be 
moved, the message "NO SPACE FOR TRACE 
TABLE" is issued. In this case, during 
ABDUMP15, the trace table will not be 
displayed. 

If the output device for the dump data 
set is not a printer, records must be 
blocked. ABDUMPl issues a conditional 
GETMAIN macro instruction to obtain space 
for the blocking of records. If space is 
not available, the processing continues 
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without the setup for the blocking of 
records • 

ABDUMPl enables interruptions and 
initializes the work area it previously 
obtained. It then invokes ABDUMPl. 5 by 
issuing an XCTL macro instruction. 



Processing during ABDUMPl. 5 
(Entry Point IGC0C05A) 

ABDUMPl. 5 displays, via a format routine 
and the Output routine, the identification 
code (if specified), the job name, step 
name, time, and date. (See sample dump in 
Section 12, "Control Blocks.") If the ABEND 
routine is the caller, ABDUMPl. 5 displays 
the completion code from the TCB for the 
specified task. Then this module displays 
(via the format and output routines) the 
old PSW stored when the ABDUMP routine was 
entered. The old PSW is displayed if it 
was requested as an operand of the SNAP 
macro instruction. Control is then passed 
to the next applicable module of the ABDUMP 
routine, via a branch to the Where-to-Go 
routine. This routine, by testing the dump 
option flags in the parameter list, deter- 
mines the next module of the ABDUMP routine 
needed to satisfy the caller's dump 
options. The Where-to-Go routine obtains 
the needed module by issuing an XCTL macro 
instruction. The XCTL request, via the SVC 
SLIH, fetches and passes control to the 
selected module of the ABDUMP routine. 



Processing during ABDUMP 2 
(Entry Point IGC0105A) 

ABDUMP2 displays all labeled fields of 
the task's TCB except its register save 
area. The register save area is displayed 
only if the caller requests the dump of 
task resources other than its own. 

ABDUMP2 scans the request blocks of the 
RB queue for the specified task to display 
the labeled fields of each request block 
(RB) . If any RB contains more than 32 
bytes, as indicated by a test of the RBSIZE 
field, its register save area and extended 
save area, if they exist, are also 
displayed. 

After all RBs on the RB queue have been 
displayed, ABDUMP2 displays the load list 
for the task, if the TCB (TCBLLS field) 
indicates that a load list exists. The 
load list contains pointers to contents 
directory entries for all modules that were 
fetched for the task via the LOAD macro 
instruction^ After all the load list ele- 
ments have been displayed, or if there was 
no load list for the task, ABDUMP2 invokes 
the next module, ABDUMP3, via an XCTL macro 
instruction. 



Processing during ABDUMP3 
(Entry Point IGC0205A) 

ABDUMP3 displays the contents directory 
entries for the task, and their extent 
lists (one for each major CDE) . The con- 
tents directory entries and their asso- 
ciated extent lists are obtained via two 
searches. The first search consists of a 
scan of the RB queue to find PRBs, each of 
which may point to a CDE. The second 
search examines the load list for the task. 
Each load list element also points to a 
CDE. Each major CDE points to its asso- 
ciated extent list. 

When all CDEs and their extent lists 
have been displayed, ABDUMP3 processing is 
complete. ABDUMP3 invokes ABDUMPQ via an 
XCTL macro instruction. 

Processing during ABDUMPQ- (Entry Point 
IGC0Q05A) 

ABDUMPQ formats and displays the data 
extent blocks (DEBs) chained from the 
TCBDEB field, and the task I/O table 
(TIOT) . DEBs chained from the OLTEP TCB 
are not formatted or displayed. When pro- 
cessing is complete, ABDUMPQ invokes 
ABDUMP4 via an XCTL macro instruction. 

Processing during ABDUMPt 
(Entry Point IGC0305A) 

ABDUMP4 displays all main storage con- 
trol blocks associated with the specified 
task, if two conditions are met: the task 
is not complete (TCBFC flag is not set) and 
there is at least one subpool queue element 
(TCBMSS pointer is not zero) . If these 
conditions exist, the following control 
blocks are displayed: 

For the Specified Task : 
Subpool queue elements (SPQEs) . 
Descriptor queue elements (DQEs) . 
Free queue elements (FQEs) . 

For the Job Step's Region (s) ; 
Partition queue elements (PQEs) . 
Free block queue elements (FBQEs) . 

If the specified task is complete or 
there are no subpool queue elements, 
ABDUMP4 displays only the PQEs and the 
FBQEs for the job-step's region (s). 

ABDUMP4 then branches to the Where-to-Go 
routine of the resident module to determine 
the next applicable module of the ABDUMP 
routine. 

The display of main storage control 
blocks is implemented as follows. The 
first step is to set nondispatchable all 
tasks in the job step except the current 
task. This is accomplished via a branch to 
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the Task Select routine of the resident 
module. (This action may already have been 
done in ABDUMPl if the specified task is 
not the current task.) The purpose is to 
prevent any program belonging to another 
task in the job step from being executed 
during an I/O wait condition of the current 
task. During such execution the program of 
the other task could issue a GETMAIN or 
FREEMAIN macro instruction, changing the 
main storage queues that are being dis- 
played for the specified task. If the mul- 
tiprocessing feature was selected, control 
is passed to the Task Removal subroutine, 
which determines whether the current task 
on the second CPU has been set nondispatch- 
able. If it has, the second CPU is inter- 
rupted with an indication (in STMASK) that 
the Dispatcher must gain control. 

ABDUMPU then formats and displays each 
SPQE in the SPQE queue and its associated 
DQEs and FQEs. If a subpool is shared, 
both the owner's and the sharer's SPQEs are 
displayed. When all SPQEs and their asso- 
ciated DQEs and FQEs have been displayed, 
if the current task is the one specified 
for the dump, ABDUMP4 branches to the Task 
Select routine to make dispatchable other 
tasks in the job step. Dispatchability is 
now feasible, since all main-storage con- 
trol blocks that are readily alterable have 
been displayed. But if the task specified 
for the dump is not the current task, the 
other tasks of the job step remain nondis- 
patchable, as set by ABDUMPl, and the 
branch to the Task Select routine is 
bypassed. 

After making other tasks dispatchable 
(if necessary) , the partition queue ele- 
ments (PQEs) and the free block queue ele- 
ments (FBQEs) for the job-step's region (s) 
are displayed. ABDUMPl then branches to 
the resident module's Where-to-Go routine 
to determine the next applicable module of 
the ABDUMP routine needed to satisfy the 
current dump request. 

Processing during ABDUMP5 
(Entry Point IGC0405A) 

ABDUMP5 displays queue control blocks 
(QCBs) and queue elements (QELs) for the 
entire job step, and/or save areas belong- 
ing to interruption request blocks (IRBs), 
depending on the dump options requested, as 
indicated by the option flags of the param- 
eter list. If the ABDUMP routine was 
invoked by the ABEND routine, all these 
items are displayed. 

If a display of QCBs and QELs for the 
job step is requested, the first step is to 
obtain the QCB origin address in the nu- 
cleus. Then, if the current task is the 
one specified for the dump, all other tasks 
in the job step are (via the Task Select 



routine) set nondispatchable. The purpose, 
as with the display of the main storage 
queues, is to prevent alteration of the QCB 
queues and QEL queues by programs belonging 
to other tasks while these control blocks 
are being displayed. If the task specified 
for the dump is not the current task, all 
tasks but the current task have been non- 
dispatchable since the execution of 
ABDUMPl. If the multiprocessing is active, 
control passes to the Task Removal subrou- 
tine, which determines whether the current 
task on the second CPU has been set nondis- 
patchable. If it has, the second CPU is 
interrupted with an indication (in STMASK) 
that the Dispatcher must gain control. 

The QEL queue chained from each minor 
QCB is searched to find QELs that belong to 
either the specified task's job step, or to 
its Initiator. For the first QEL that 
schedules a given job-step resource, 
ABDUMP5 displays both the QEL and its asso- 
ciated QCB. For each other QEL for the 
resource, only the QEL is displayed. 
ABDUMP5 compares two PQE pointers to deter- 
mine whether a given QEL belongs to the 
current job step (including its Initiator) . 
One of the PQE pointers (TCBPQE) is in the 
TCB whose address is contained in the QEL. 
The other PQE pointer is in the current TCB 
under whose control the ABDUMP routine is 
operating. If the two PQE pointers are 
equal, both TCBs belong to the same job 
step (or one represents the Initiator) , 
since they both refer to the same region of 
main storage. In this case, the QEL is 
displayed. The examination and display of 
QELs belonging to the job step continue 
until all QELs have been examined, as indi- 
cated by a major-QCB chain address of zero. 

If the current task is the one specified 
for the dump, all other tasks are next set 
dispatchable. But if the specified task is 
not the current task, other tasks are still 
nondispatchable as set by ABDUMPl, and this 
step is bypassed. 

The next step is to display user-program 
save areas belonging to IRBs, if a save- 
area trace has been requested. If a save- 
area trace has not been requested, no 
further processing occurs in ABDUMP5, and a 
branch is made to the Where-to-Go routine 
of the resident module to determine the 
next module of ABDUMP to be invoked. 

If a save-area trace has been requested 
as an option of the SNAP macro instruction, 
ABDUMP5 examines each RB on the RB queue of 
the specified TCB. For each IRB on the 
queue, the register save area is displayed. 
When the save areas of all IRBs on the RB 
queue have been displayed, ABDUMP5 process- 
ing is complete. ABDUMP6 is invoked, via 
an XCTL macro instruction, to continue the 
display of save-area information. 



216 



Processing durincr ABDUMP6 
(Entry Point IGC0505A) 

ABDUMP6 provides the heading line "SAVE 
AREA TRACE." The heading identifies the 
following lines as a trace of the program- 
provided register save areas for the task 
being dumped. Each save area is displayed 
in three printable lines, starting with the 
supervisor-provided save area for the first 
user routine of the task. 



Save areas are displayed initially in a 
"forward" order, the order in which the 
associated routines were invoked by LINK or 
CALL macro instructions. The forward trace 
continues until all program- provided save 
areas have been displayed, or until incor- 
rect forward or back chaining of save areas 
is discovered. Then, ABDUMP6 performs a 
partial "backward" trace, displaying the 
save areas for the two most recently 
executed user routines. 



In addition to the address and contents 
of each save area, ABDUMP6 displays the 
following messages: 



• An "interruption" message, giving the 
address of the next executable instruc- 
tion of the newest user routine of the 
task. 



• A message stating the type of linkage 
macro instruction (LINK or CALL) that 
was first used for the task. 

• A message identifying the display of 
the backward trace. 

The save area trace is now described in 
greater detail. (See Figure 10-6.) 

The forward trace begins as ABDUMP6 
obtains the address of the supervisor- 
provided save area for the first executed 
user routine of the task. This save area 
is pointed to by the TCBFSA field of the 
TCB. ABDUMP6 checks the validity of the 
save area address. If the address is in- 
valid (zero or not on a fullword boundary) , 
most of the save area trace is bypassed and 
only the save areas for the two last 
executed routines of the task are dis- 
played. But if the address of the 
supervisor-supplied save area is valid, 
information for the first-executed routine 
of the task is displayed (Figure 10-6, part 
1) . The information includes the type of 
linkage (LINK or CALL) , the module name 
(obtained from the module's CDE) , and the 
entry point identifier (if it was specified 
as an operand of the LINK or CALL macro 
instruction) . 



ABDUMP6 tries to complete the forward 
save area trace by performing the following 
steps: 

• It obtains the forward chain pointer 
from the third word of the supervisor- 
provided save area and checks the 
pointer for validity (Figure 10-6, part 
1, block F). 



• If the forward chain pointer is valid, 
it obtains the backward chain pointer 
from the second word of the next save 
area and checks the pointer for validi- 
ty (Figure 10-6, part 2, block B) . 



• If the backward chain pointer is valid, 
it displays the save area and its 
address (Figure 10-6, part 2). 

These steps are repeated for each save 
area until all save areas have been dis- 
played, as indicated by a forward chain 
pointer of zero, or until an invalid for- 
ward chain pointer or backward chain point- 
er has been detected. If ABDUMP6 detects 
an invalid backward chain pointer, it 
issues an error message "INCORRECT BACK 
CHAIN" and displays the associated save 
area. 

ABDUMP6 next prepares for the partial 
backward trace that displays the register 
save areas for the two most recently 
executed user routines. It first obtains 
the address of the newest PRE on the task's 
RB queue (see Figure 10-6, part 5). This 
PRE represents the last executed user rou- 
tine. ABDUMP6 then writes the interruption 
message consisting of the words "INTERRUPT 
AT," followed by the second half (address 
word) of the RB old PSW in the PRB. As a 
heading for the backward trace, ABDUMP6 
issues the message "PROCEEDING BACK VIA REG 
13." 

ABDUMP6 then performs the partial back- 
ward trace. It first obtains the address 
of the save area for the last executed user 
routine of the task. This address is in 
the register 13 save location in the SVRB 
that precedes the newest PRB on the task's 
RB queue (Figure 10-6, part 6, block X). 
This save area address and the associated 
backward chain pointer (Figure 10-6, part 
H, block B) are validity checked, and the 
two save areas and their addresses are dis- 
played (Figure 10-6, parts 3 and 4). 
ABDUMP6 then branches to the Where-to-Go 
routine of the resident module to determine 
the next transient module of the ABDUMP 
routine to be invoked. The Where-to-Go 
routine makes the decision on the basis of 
the dump options specified by the ABDUMP 
routine's caller (as indicated by the 
option flags in the dump parameter list) . 
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Figure 10-6. Pointers Used During the Save Area Trace 



Processing during ABDUMPll (Entry Point 
IGC0B05A) 

ABDUMPll displays the prefixed storage 
area (8) in the nucleus of main storage. If 
the partitioned mode is operating, only the 
prefixed storage areas at the lower end of 
main storage is displayed, preceded by the 
heading "GPU A PSA" or "CPU B PSA." If the 
multisystem mode is operating, both pre- 
fixed storage areas are displayed, preceded 
by the headings "CPU A PSA" and "CPU B 
PSA." ABDUMPll invokes ABDUMP7 via an XCTL 
macro instruction. 

In a multiprocessing system, ABDUMP7 
omits the prefixed storage area from the 
display of the nucleus, and ABDUMP15 does 
not display the trace table. 



Processing during ABDUMP7 
(Entry Point IGC0605A) 

ABDUMP7 displays any combination or all 
of the following resources of the specified 
task, depending on the options requested by 
the caller. 

• The nucleus of main storage. 

• The register contents when the ABEND 
routine was entered, or when the SNAP 
macro instruction was issued. 



• Selected blocks of main storage (if 
STORAGE is included as a keyword 
operand of the SNAP macro instruction) . 

If the caller has requested a dump of 
the nucleus of main storage, ABDUMP7 dis- 
plays the nucleus, preceded by the heading 
NUCLEUS. If there is a trace table in the 
system, and it lies in the nucleus, only 
the part of the nucleus below the trace 
table is displayed (see ABDUMPl for a dis- 
cussion of the trace table) . Then the 
heading NUCLEUS CONT and the rest of the 
nucleus above the trace table are dis- 
played. ABDUMP7 bypasses the current copy 
of the trace table because the table now 
contains misleading information. This 
information was inserted after SVC inter- 
ruptions, I/O interruptions, and entries to 
the Dispatcher, during execution of the 
ABDUMP routine. The original copy of the 
trace table was saved by ABDUMPl, if space 
was available, and is displayed by 
ABDUMPl 5. 

In a multiprocessing system, the pre- 
fixed storage area(s) are displayed by 
ABDUMPll (IGC0B05A) . Therefore, ABDUMP7 
displays the nucleus starting at location 
X'lOOO.' 

ABDUMP7 next displays the register con- 
tents as they appeared when the SNAP macro 
instruction was issued. If the ABEND rou- 
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tine was the caller, the register contents 
are obtained from the ABEND routine's SVRB. 
Otherwise, the register contents saved in 
the ABDUMP routine's SVRB are used for the 
display. The display is preceded by either 
of two messages: "REGS AT ENTRY TO ABEND" 
or "REGS AT ENTRY TO SNAP." 

If a SNAP macro instruction was issued 
with the keyword STORAGE, the areas of main 
storage requested by the caller are for- 
matted and displayed. To protect private 
information, storage is displayed only if 
it lies within the caller's region. Each 
eight words of storage is preceded by its 
starting address. ABDUMP7, its processing 
now complete, branches to the Where- to-Go 
routine of the resident module to determine 
the next transient module of the ABDUMP 
routine to be invoked. 

Processing during ABDUMP8 
(Entry Point IGC0705A) 

ABDUMP8 displays load modules for the 
task whose resources are being dumped. The 
information needed to display each load 
module is obtained from the contents direc- 
tory entry (CDE) for the module and from 
the associated extent list. 

There are two possible sources of infor- 
mation needed to dump load modules. One 
source is the group of CDEs pointed to by 
PRBs belonging to the task. These CDEs 
represent modules requested by an ATTACH, 
LINK, or XCTL macro instruction. The other 
source is the group of CDEs pointed to by 
elements of the load list for the task. 
These CDEs represent modules requested by a 
LOAD macro instruction. (For a review of 
the contents directory and the load lists, 
see Section U, "Contents Supervision.") If 
the task specified for the dump has already 
been terminated, either normally or abnor- 
mally, as indicated by the "set" condition 
of the TCBFC flag, all PRBs have been 
removed from the task's RB queue and have 
been freed. To determine if the RB queue 
still exists and can be examined, ABDUMP8 
examines the TCBFC flag to test for pre- 
vious task termination. If the task was 
not terminated, both the RB queue and the 
load list are scanned for pointers to CDEs. 
(For the content and format of a PRB, a 
CDE, a load list element, and an extent 
list, see Section 12, "Control Blocks and 
Tables.") 

ABDUMP8 obtains the following informa- 
tion from the CDEs: 

• Whether the module is already in main 
storage or in the process of being 
fetched. 

• The address of the module's extent 
list. The extent list contains the 



main storage address and length of each 
loadable section of the module. 

• The module's entry point name. 

• Whether the module is in the area of 
main storage specified by the caller 
(job pack area or link pack area). 

If the module is in the specified main 
storage area, ABDUMP8 displays a heading 
line, containing "LOAD MODULE" and the 
module's name, followed by the contents of 
the module itself. The normal line of the 
display contains eight words of storage 
preceded by their starting address. 

When the load modules described by all 
CDEs have been displayed, ABDUMP8 branches 
to the Where-to-Go routine of the resident 
module. This routine determines whether 
ABDUMP9 should be invoked, or whether con- 
trol should be returned to the caller of 
the ABDUMP routine. 

Processing during ABDUMP9 
(Entry Point IGC0805A) 

ABDUMP9 displays user subpools of main 
storage that have subpool numbers not 
greater than 127. When all user subpools 
have been displayed, ABDUMP9 branches to 
the Where-to-Go routine of the resident 
module (lEAQADOA), to prepare for and 
return control to the caller of the ABDUMP 
routine. 

ABDUMP9 displays user-obtained main 
storage if two conditions exist: there is 
at least one subpool queue element (SPQE) 
on the task's main storage queues (TCBMSS 
flag is not zero) , and the SPLS operand was 
specified in the SNAP macro instruction. 
Otherwise, ABDUMP9 branches to the Where- 
to-Go routine in the resident module (lEA- 
QADOA) to end the dump and return control 
to the caller. 

If user main storage is to be displayed, 
the job step is set temporarily nondis- 
patchable to prevent alteration of the main 
storage queues during the display. If the 
multiprocessing feature was selected, con- 
trol is passed to the TESTDSP subroutine 
which determines whether the current task 
on the second CPU has been set nondispatch- 
able. If it has, the second CPU is inter- 
rupted with an indication (in STMASK) that 
the Dispatcher must gain control. 

For each subpool queue element (SPQE) , 
ABDUMP9 checks that the subpool number is 
for a user area of storage, as indicated by 
a subpool number not greater than 127, and 
that the SPQE does not represent a shared 
area of storage. (For the content and for- 
mat of an SPQE see Section 12, "Control 
Blocks and Tables.") If the SPQE indicates 
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that the area is shared, the "dvmer" SPQE 
is obtained via an SPQE pointer in the DQE- 
pointer field of the SPQE. The "ovmer" 
SPQE is the element created by the GETMAIN 
routine when the block of storage was first 
requested. 

ABDUMP9 obtains from the descriptor 
queue element (DQE), pointed to by the 
SPQE, the starting address of the block of 
main storage for the original GETMAIN re- 
quest and the number of bytes allocated for 
the request. ABDUMP9 displays a header 
line giving the subpool and block number. 
The subpool number is obtained from the 
SPQE, the block number from the DQE. It 
then formats the block, normally eight 
words to a line, and displays it. There 
may be one or more free areas in the block 
to be displayed, as indicated by the exis- 
tence of a free queue element (FQE) pointed 
to by the DQE. In this case, ABDUMP9 
divides the block into sections separated 
by free areas. It then formats and dis- 
plays the block, bypassing each free area, 
so that free areas do not appear in the 
dump output. The process is repeated for 
each DQE belonging to an SPQE and for each 
SPQE in the queue. When all SPQEs have 
been processed, ABDUMP9 sets all other 
tasks of the job step dispatchable. Since 
the display of user-acquired main storage 
is finished, GETMAIN requests will not now 
affect the dump, ABDUMP9 then branches to 
the Where-to-Go routine of the resident 
module CIEAQADOA) to prepare for return of 
control to the caller: the ABEND routine 
or the issuer of the SNAP macro 
instruction. 

Processing during ABDDMP12 (Entry Point 
IGC0J05A) 

ABDUMP12 displays the GTF trace data if 
it exists in main storage and is requested 
as part of the dump. A header record is 
printed first. Then, the oldest record in 
the GTF trace buffer is obtained and the 
data formatted and printed. Formatting 
proceeds from the oldest record to the most 
current. Control is transferred to 
ABDUMP14 (IGC0M05A) when a control record 
(time records and lost-event-count records) 
or error records are encountered. 



Processing during ABDUMPlt (Entry Point 
IGC0M05A) 

ABDUMPlt formats and prints GTF control 
and error records. The control records 
consist of the time record (created if the 
keyword TIME=YES was used in the START com- 
mand) and the lost- event- count record. 
When an error record is encountered, 
ABDUMP14 selects the appropriate message 
and dumps the error record in hexadecimal. 



Control is returned to ABDOMP 12 or 
ABDUMP in. 



Processing during ABDDMP15 (Entry Point 
IGC0N05A) 

ABDUMP15 displays the optional supejrvi- 
sor trace table if it exists in the system 
and was requested as part of the dump, and 
if the table was saved during ABDOMPl. In 
a multiprocessing system, the trace table 
is displayed by ABDUMP16 (IGC0P05A) and, 
therefore, is not displayed by ABDUMP15. 



ABDUMP15 displays the trace table in two 
parts. (The program listing calls this 
procedure "unfolding" the trace table.) 
ABDUMP15 starts the display at the trace 
table entry immediately after the current 
entry, and proceeds to the end of the 
table. It then displays the rest of the 
table by starting at the first entry and 
proceeding to the current entry. Pointers 
to the trace table exist in a triple word 
whose address is obtained from the secon- 
dary communication vector table (see Sec- 
tion 12, "Control Blocks and Tables"). The 
first word points to the address of the 
current entry of the trace table; the 
second word points to the start of the 
table; the third word points to the end of 
the table. 



After displaying the trace table, 
ABDUMP15 frees the space previously 
obtained for the table and then branches to 
the resident module (lEAQADOA) . 



When all records have been formatted and 
printed, GTF tracing is resumed and control 
is transferred to the ABDUMP resident 
module (lEAQADOA) . 

Processing during ABDUMP13 (Entry Point 
IGC0K05A) 

ABDUMP13 displays the GTF trace data in 
a multiprocessing system if it exists in 
main storage and is requested as part of 
the dump. The function of this module is 
very similar to ABDUMP12. 



Processing during ABDUMP16 (Entry Point 
IGC0P05A) 

ABDUMP16 is executed only in a multi- 
processing system. It displays the trace 
table if it exists in the system, was 
requested as part of the dump, and was 
saved during ABDUMPl. The character A or B 
is printed on each line/entry to identify 
the CPU to which the line/ entry applies. 
The trace table is displayed as in a 
uniprocessing system (see Processing During 
ABDUMP15). 
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Processing during ABDUMPH (Entry Point 
IGC0H05A) 

If the dump request is for a time shar- 
ing task, ABDUMPH formats and displays the 
protected storage control block (PSCB), the 
user profile table (UPT) , and the data set 
extension (DSE) . ABDUMPH then passes con- 
trol to ABDUMP9. 



Processing during ABDUMPI (Entry Point 
IGC0I05A) 

If the dump request is for a time shar- 
ing task, ABDUMPI formats and displays the 
terminal job block (TJB) and the terminal 
job block extension (TJBX) . ABDUMPI then 
passes control to the Where-to-Go routine. 

TCAM ABDUMPI (Entry Point IGC0D05A) 

TCAM ABDUMPI receives control from the 
resident ABDUMP module (lEAQADOA) when the 
program being dumped is the Telecommunica- 
tions Access Method Message Control Pro- 
gram- TCAM ABDUMPI foinnats and prints the 
header line, the address vector table 
(AVT) , and the basic section of the termin- 
al name table (TNT) . The AVT is dumped in 
three parts — the basic section, the 
storage queue section, and the disk sec- 
tion. Then the TNT section is dumped and 
control is passed to TCAM ABDUMP2. 

TCAM ABDUMP2 (Entry Point IGC0E05A) 

TCAM ABDUMP2 dumps the entries in the 
TNT and their associated terminal table 
(TRM) entries. First, the TNT entry is 
formatted and immediately after, its asso- 
ciated TRM entry is also formatted. This 
is repeated for every TNT entry. Control 
is then passed to TCAM ABDUMP3. 

TCAM ABDUMP3 (Entry Point IGC0F05A) 

TCAM ABDUMP3 dumps the TCAM destination 
queue control blocks associated with the 
TRM entries. They are located through the 
TNT entries, and are formatted in the order 
of ascending storage locations. After all 
the QCBs have been dumped, control is 
passed to TCAM ABDUMPU. 

TCAM ABDUMPt (Entry Point IGC0G05A) 

TCAM ABDUMPU dumps the three types of 
TCAM DCBs (line group, message queue, and 
checkpoint) and the line control blocks 
associated with each line group DCB. Only 
open TCAM DCBs are dumped. The order in 
which they are dumped depends on the order 
in which their corresponding DEBs are 
chained. The line control blocks for each 
line group DCB are formatted immediately 
after their associated DCBs. When all DCBs 
have been printed, control is transferred 



to the "Where-to-Go" routine in the resi- 
dent ABDUMP routine. 

Cleanup in the Where-to-Go Routine 

The cleanup procedure of the Where-to-Go 
routine of the resident module (IGC0A05A) 
ends the dump and prepares for return of 
control to the caller by: 

• Displaying message "END OF DUMP." 

• Freeing all areas obtained during the 
execution of ABDUMPI (that is, the work 
area and the optional area for the 
blocking of records). 

• Issuing a DEQ macro instruction for the 
dump data set, if the ABDUMP routine 
was invoked by a user routine. If the 
ABDUMP routine was invoked by the ABEND 
routine, the ABEND routine issues the 
DEQ macro instruction, specifying the 
dump data set. The data set can then 
be used by the ABDUMP routine for 
another caller specifying the same data 
set. 

• Deletes the resident module and returns 
control to the caller, via the Exit 
routine and the Dispatcher. It does 
this by moving a DELETE macro instruc- 
tion and an SVC-3 instruction to the 
extended save area of the ABDUMP rou- 
tine's SVRB, and then executing these 
instructions. In the program listing 
this process is called "self delete." 

SVC DUMP (Entry Point IGC0005A) 

SVC DUMP provides a dump of selected 
areas of main storage to either tape or a 
direct access device. When invoked by DAR 
or SVC 34, it writes the dump of main 
storage to the SYSl.DUMP data set. When 
invoked by any other supervisor routine, 
the dump is written to a user defined data 
set. 

SVC DUMP 1 (lEAQADOY) is entered at 
entry point IGC0005A when the caller issues 
an SVC 51- Initially, SVC DUMP 1 checks 
the ABDUMP parameter list to determine if 
the request is for a SNAP or an SVC DUMP. 
If the request is for a SNAP, control 
passes to ABDUMPI (lEAQADOO). Otherwise, 
SVC DUMPl checks the highest level RB of 
the invoking task to ensure it is operating 
with a protection key of zero, that is, to 
ensure that it is in supervisor state. If 
it is not, the dump exits with a return 
code. 

The lock byte is then tested to deter- 
mine whether a dump is already in progress. 
If it is, the dump exits with a return 
code. If it is not, the lock byte is set 
to prevent simultaneous access to dump data 
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sets. Next all tasks, except the communi- 
cations. Fetch, System Error, and current 
tasks, are set nondispatchable and the dump 
invoked bit in the TCB is turned on. 

If the caller does not supply a DCB 
address, the SYSl.DUMP data set is used. 
If the data set, user-supplied or SYSl. 
DUMP, is not open, SVC Dump 1 exits with a 
return code. 

SVC DUMP 1 then issues the TIME DEC 
macro instruction to obtain the date and 
time. These are stored in the header 
record. 

The UCB representing the device upon 
which the dump data set resides is checked 
to ensure that it is in the "ready" state. 
If it is not, a return code is set and the 
routine exits after resetting dispatchabi- 
lity bits and the lock byte. The device 
type, either tape or direct access, is then 
determined and initialization of the con- 
trol blocks is completed as required. 

The optional trace table (if present) , 
or GTF (if active) , are made inoperative 
for the duration of the dump so that 
entries leading up to the failure are pre- 
served. Prior to exiting, the supervisor 
trace table or GTF is reactivated. 

If the device is direct access, a test 
is required to determine if the data set is 
available to receive a dump of main 
storage. A channel program is initialized 
to READ the first record on the data set. 
If EOF is not detected, the data set alrea- 
dy contains a dump of main storage, in 
which case a return code is set and the 
routine exits. Otherwise, the data set is 
empty and available to receive a dump of 
main storage. The user supplied header 
record is the first data block written. 
After this the channel programs are rein- 
itialized to perform the actual writing of 
the dump of main storage. 

Abnormal end, channel end, and program 
controlled interrupt appendages are pro- 
vided. The writing of the diimp is per- 
fonned via EXCP and WAIT. The PCI appen- 
dage performs the updating of the channel 
programs required to write the dump. The 
channel end and abnormal end appendages are 
provided to restart the channel program if 
end of cylinder or I/O errors are encoun- 
tered. Standard ERPs are used while writ- 
ing the dump except if SVC DUMP was invoked 
due to a failure of the System Error Task. 

An unrecoverable error condition causes 
the writing of the dump to be terminated 
and a return code set prior to exiting. 
Upon completion of the dump, a normal com- 
pletion return code is set. For SYSl.DUMP 
an EOF record is written after the dump is 



completed (normally or abnormally) . For 
user DASD data sets, the DCBFDAD field in 
the user's DCB is filled in with the 
address of the last block written. The 
DCBTRBAL field is set to zero if the last 
record written filled a track. Otherwise, 
it is set to 1024. These steps are 
required to present a standard DCB inter- 
face to close. All tasks are set dispatch- 
able prior to exiting, the lock byte is 
reset, and the "dump invoked" bit is turned 
off- Control then returns to the caller. 

If the device is tape, control passes to 
SVC DUMP 2 (lEAQADOZ) at entry point IGCOZ- 
05A. When writing to tape, processing is 
basically the same as direct access with 
the exception that the PCI and CE appen- 
dages are not used. A tapemark is written 
only for a NIP allocated tape unit. If the 
tape is user-supplied, no tapemark is writ- 
ten. The user must close the DCB. The 
"LEAVE" option may be specified thus allow- 
ing multiple dumps on tape. 

SVC DUMP 2 checks for unit exception 
after data is written to tape. If a unit 
exception occurs, the dump is terminated 
for lack of space. In this case, a tape- 
mark is written and the tape unloaded „ A 
special return code is provided. If a 
channel data check occurs, the dump is con- 
tinued at the next storage address to be 
displayed. 

If dump storage boundaries are indicated 
in the parameter list, the dump routine 
dumps storage from the addresses specified. 
Beginning addresses are rounded down to a 
2K boundary; ending addresses are rounded 
up to a 2K boundary. If the parameter 
lists indicate that nucleus and SQA are to 
be dumped, this is done first. All parame- 
ters are validity checked. If invalid, the 
dump is terminated with an error return 
code- 

Upon completion of the last WRITE, SVC 
DUMP 2 returns to the caller after setting 
all tasks dispatchable, turning off the 
lock byte and dump invoked bit, and reacti- 
vating the optional trace table or GTF 
tracing. 



PERFORMING ABNORMAL TERMINATION 
(ABEND ROUTINE) 

Abnormal termination occurs when some 
type of unrecoverable error, such as a 
machine check, I/O error, or program check 
has taken place. It may also be initiated 
by a system or user program that detects an 
abnormal condition that could cause a pro- 
gram check or incorrect processing. The 
task whose program or I/O operation has 
malfunctioned is abnormally terminated 
because reliable results can no longer be 
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obtained. The task must be terminated to 
prevent waste of system resources, such as 
CPU time or main storage. 



The purpose of abnormal termination is 
to free the resources of the malfunctioning 
task so that they can be made available to 
other tasks in the system. The freed 
resources include programs in main storage, 
enqueued resource requests, unexpired timer 
requests, incomplete operator communica- 
tions, exclusively used data sets, and 
unshared subpools of main storage (if 
dynamically acquired) . These resources 
belong to the specified task itself and its 
previously unterminated descendants. In 
addition, control blocks used by the ter- 
minating task and its descendants are 
dequeued from their lists and in most cases 
freed. These control blocks include: 
TCBs, RBS, IQEs, QELs, QCBs, SPQEs, CDEs, 
TQEs, SCBs, and PIEs (if they exist). 

Abnormal termination allows two options ; 
task and job-step termination. These are 
normally user options, specified by an 
operand of the ABEND macro instruction. 
This option permits a program belonging to 
a higher level task in the job step to 
decide whether to continue or terminate the 
other tasks of the job step. In task ter- 
mination the resources of only the malfunc- 
tioning task and its previously unter- 
minated descendants are released. But in 
step termination the resources used by all 
tasks of the job step are freed. Step ter- 
mination may be elected by a user program 
(via the STEP operand of the ABEND macro 
instruction) , or caused by internal ABEND 
processing in the case of a "steal core" or 
a DAR (Damage Assessment Routine) 
conversion. 

The termination procedure is performed 
by the ABEND routine. As stated before, 
the ABEND routine frees resources and con- 
trol blocks belonging to the malfunctioning 
task and its previously unterminated 
descendants (subtasks, and subtasks of sub- 
tasks) . For several unusual conditions (a 
task in "must complete" status, a terminat- 
ing system task, or an invalid recursion) , 
the ABEND routine exits to the Damage 
Assessment Routine (DAR), which alters the 
environment so ABEND or system processing 
can attempt to continue, or sets all tasks 
in the job step nondispatachable. 

If the dump option had been selected 
(either by the user program or by the 
ABTERM routine) , the ABEND routine causes 
the loading and execution of the ABDUMP SVC 
routine. The ABDUMP routine displays the 
programs, control blocks, and dynamically 
acquired storage of the terminating task, 
its descendants, and its ancestors, includ- 
ing the job-step task. 



The ABEND routine may be invoked direct- 
ly or indirectly. The invocation is direct 
when a system or user routine issues an 
ABEND macro instruction to terminate the 
current task. The invocation is indirect 
when a system routine, after detecting an 
abnormal condition, branches to the ABTERM 
routine. The ABTERM routine schedules the 
execution of an SVC 13 (ABEND macro 
instruction) for the task to be terminated. 
The SVC 13 instruction, executed when the 
task to be terminated is next dispatched, 
causes supervisor linkage to the ABEND 
routine. 

The entry is indirect in the following 
situations: 

• A type-1 SVC routine, which is not per- 
mitted to issue an SVC instruction, 
decides to terminate the current task. 

• A supervisor routine decides to termi- 
nate a task other than the current 
task. 

• The I/O Supervisor, whose execution is 
asynchronous with task performance, 
decides to terminate a task for which 
an unrecoverable I/O error has 
occurred. 

• A program check occurs during the per- 
formance of any task. 

• A 0F3 machine check for some task in 
the job step. 

Recursions 

An error condition may occur during 
ABEND processing that results in a new re- 
quest for abnormal termination of the task 
that is already being terminated. A new 
entry to the ABEND routine must be sche- 
duled so ABEND can try, if possible, to 
complete termination procedures. Such a 
reentry to the ABEND routine for the same 
task is called a reciirsion. Certain recur- 
sions are valid (ABEND expects the possibi- 
lity of an ABEND at that point) , and the 
module continues normal processing with any 
special handling necessary. Invalid recur- 
sions, when detected, are handled by pas- 
sing control to DAR which takes a dump and 
attempts to continue the termination if 
possible. 

The task control block (TCB) contains a 
TCBRECDE field which specifies configura- 
tions for valid ABEND recursions. This 
field is checked for the pairticular type of 
recursion, and ABEND processing continues 
based on the configurations. ABEND3 checks 
this field and routes control to the proper 
modules to handle it. The valid recursion 
configuration flags are set prior to any 
processing during which a possible ABEND is 
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expected. They are then cleared immediate- 
ly after completion of that particular pro- 
cessing. This is done so that ABEND does 
not misinterpret a futiire invalid recursion 
as valid. Following is a list of the 
TCBRECDE flags and the valid recursions 
they indicate. The TCBREC flag indicates 
that a valid recursion exists; this bit is 
checked in ABENDO and ABENDl. For a first- 
time entry this bit is zero; for a valid 
recursion this bit is one. For a valid 
recursion, ABENDl turns this bit off and 
processing continues based on the status of 
the right-most bits of the TCBRECDE field. 
These remaining bits, shovm in Figure 10-7, 
indicate the specific recursion. 



Communications 

The TCBRECDE field is also used for 
parameter type information in communicating 
between various modules. When used for 
communications, the TCBREC bit is always 
zero. The following is a list of the com- 
munication configuration flags used between 
ABEND/ASIR/DAR modules: 

TCBNOSTA — Indicates that STAE/STAI 

(Specify Task Abnormal Exit/ 
Subtask ABEND Intercept) not 
to be honored. 

TCBSTRET — Indicates a return from the 
"steal core" routine - 

TCBCONVR — Indicates a conversion to a 
job-step ABEND is necessary. 

TCBDARET — Indicates a return from DAR. 

TCBNEWRB — Indicates that ABEND issued 
an SVC 13 to pass control, 
via an XCTL, to a non-ABEND 
module . 

Issuing A Conditional Freemain 

Because certain ABEND modules must not 
be interrupted by other abnormal termina- 
tion conditions, and to bypass excessive 
recursion processing, special linkage is 
provided within several ABEND modules and 
ABTERM to handle error conditions that may 
occur within a FREEMAIN. An ABEND condi- 
tion may result during a FREEMAIN because 
of the following two cases: (1) the user 
may have freed up system control blocks in 
his storage area; the task abnormally ter- 
minates when it attempts to free these same 
control blocks; or (2) the user may have 
destroyed a free queue element (FQE) near 
the area being freed; FREEMAIN detects the 
invalid FQE when ABEND attempts to free the 
FQE. 

The ABEND modules set the first byte in 
the SCVTFMSA field to X'80' before invoking 
a conditional FREEMAIN across a branch 
entry. The branch itself prohibits ABEND 
from losing control to the SVC FLIH and the 
Dispatcher. If an error condition occurs 
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within FREEMAIN, ABTERM is entered to sche- 
dule abnormal termination of the task. 
However, when ABTERM encounters the X'80' 
in the first byte of SCVTFSMA, normal 
ABTERM processing is bypassed, and ABTERM 
loads registers 2-14 from the FREEMAIN 
save area, and returns control to the ABEND 
module using a BR 14 instruction. ABEND 
then resets the SCVTFSMA field, and proces- 
sing continues even though the specified 
area was not freed. 

Often the ABEND routine must branch to 
subroutines within the Exit/End-of-Task 
routine to fulfill certain necessary func- 
tions. If these subroutines may free areas 
in unprotected storage, ABEND sets the 
SCVTFMSA field to X'tO'. This indicates to 
the subroutine that, because the entry is a 
branch entry from ABEND, a conditional 
FREEMAIN should be performed. 



ABEND Processing 

ABEND processing follows a logical, 
functional sequence. Certain actions must 
precede others. The following is a general 
list of the types of functions included in 
ABEND, arranged in the order in which they 
should occur. If a new function were to be 
added which did not fit into any of these 
ten classes, a new class of functions would 
be incorporated into its proper place. 
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Functions that must be performed prior 
to deciding whether the ABEND should 
continue. 

Functions that must be performed for a 
real ABEND prior to losing control via 
an XCTL. 

Fimctions that seriously degrade the 
performance of other tasks until they 
are performed. 

Functions that must be performed prior 
to routing control to DAR. 

Functions that must be performed (a) 
for all non-DAR entries, (b) prior to 
providing diagnostic aids to the pro- 
blem programmer, and (c) while the 
originally terminating task is in 
control. 

Functions that must be performed only 
once per ABEND, regardless of recur- 
sions, and must be performed prior to 
providing diagnostic aids. 

Functions that provide diagnostic aids 
to the problem programmer (for 
example, a SYSUDUMP/SYSABEND dump) . 

Functions that must be performed under 
control of each terminating task. 

Functions that may be performed under 
control of the top terminating task's 
TCB. 

Final processing for the top task that 
must be performed at a time in which 
ABEND will not lose control. 



ABEND Modules 

The ABEND routine is composed of several 
transient modules. Some modules are 
entered only once per ABEND, and some on 
every recursion. All modules, except 
ABEND16 and ABEND20, must issue an XCTL 
macro instiniction at the end of processing 
to cause supervisor linkage to the Tran- 
sient Area Handler which fetches and passes 
control to the next module. 

Following is a list of the ABEND modules 
and a brief description of their functions. 

ABENDO gains control after an SVC 13 
instruction is issued either by the caller, 
or indirectly by the ABTERM routine. It 
handles initial interfaces for SVC DUMP, 
Generalized Trace Facility, STAE/STAI, TSO, 
and ABDUMP. ABENDO also purges I/O for the 
current task, prevents asynchronous exits, 
performs ABEND/ABTERM housekeeping func- 
tions, and routes control to DAR for inva- 
lid recursions. 



ABENDl purges I/O and AEQs for each 
entry into the ABEND routine. Timer and 
WTOR requests are purged for first-time 
entries only. ABENDl performs conversion 
to a job-step ABEND, sets subtasks nondis- 
patchable, validity checks the FQE, 
releases the PIE, and routes serious errors 
to DAR. 



ABEND3 releases partially loaded pro- 
grams, purges type-1 message list elements 
(on recursion) , and routes control for 
valid recursions. 

ABEND U writes type-1 messages, purges 
message list elements, and frees type-1 
message WTP buffers. 

ABENDS purges Rollout requests. 

ABEND7 provides an interface with the 
Graphics Debug routine, and the Direct SYS- 
OUT writer. 

ABENDS opens the dump data set, and 
saves and restores both the load list ele- 
ment (LLE) pointer, and the current TCBMSS 
pointer (pointer to SPQEs for the current 
task) . 

ABEND9 processing is concerned mainly 
with providing diagnostic aids. It loads 
ABDUKP's resident module, enqueues on the 
dump data set, and gives an ABDUMP via SNAP 
(SVC 51) . After completing these func- 
tions, ABEND9 dequeues on the dump data set 
and deletes the ABDUMP module. 

ABENDll provides the following data 
management interfaces and related purges — 
erases complete subtasks, moves the ABEND 
SVRB around the terminating tree and dis- 
patches under each TCB, checks for storage 
for the Close routine and routes to the 
"steal core" routine, closes open data 
sets, and frees the PIE. 

ABEND12 performs the "steal core" func- 
tions for the Close routine. 

ABENDl 3 performs data management and 
subsystem interfaces and purges. It rein- 
itializes some queues for the TCAM task, 
cancels pending Inter-Partition Posts for 
user and TSO tasks, and frees SCBs. 
ABEND13 also purges QELs, transient SVRBs, 
and routes for TIOT cleanup. 

ABEND15 purges CDEs, associated pro- 
grams, and extent lists. 

ABEND16 purges IRBs, PRBs, resident 
SVRBs, the load list, and main storage. It 
also dequeues and erases subtask TCBs. 
ABEND16 then returns control to the current 
routine of the highest priority ready task 
by exiting to the Normal Termination rou- 
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tine and the Dispatcher (via an SVC 3 
instruction) . 

ABEND20 performs Storage Reconfiguration 
in a Model 65 Multiprocessing System. 

Processing during ABEHDO (Entry Point 
IGCOOOIC) 

The SVC SLIH fetches the first module of 
the ABEND routine (ABENDO) from the SVC 
library. The SVC SLIH then gives control 
to ABENDO, via the Dispatcher. 

ABENDO handles the interfaces between 
ABEND and the following functions: 

• SVC DUMP 

• GTF (Generalized Trace Facility) 

• STAE/STAI (Specify Task Abnormal Exit/ 
Subtask ABEND Intercept) 

• TSO (Time Sharing Option) 

• ABDUMP 

ABENDO first tests if this entry to 
ABEND is a return from a STAI exit routine 
through ASIRl (ABEND/STAE Interface Routine 
1) . If so, ABENDO sets the TCBFX flag to 
prevent asynchronous exits, and turns off 
the ABEND communication configuration indi- 
cator. Processing continues with the Purge 
I/O routine. 

For a normal entry to ABEND, the ABEND 
SVRB extended save area is zeroed out and 
"ABEND* is moved to its end. ABENDO then 
sets the TCBFX flag, preventing asynch- 
ronous exits . 

If the TCBNEWRB flag is on, a new SVRB 
has been created by an SVC 13 issued by 
ABEND. This new SVRB is used to give con- 
trol to a non -ABEND module via XCTL. When 
the non- ABEND module is finished, it exits 
and the previous ABEND module gains control 
immediately following the SVC it issued. 
The name of the module to get control is in 
bytes 8-15 of the previous ABEND'S SVRB 
extended save area; the recursion confi- 
guration to be used is in byte 16. 

ABENDO next determines if this is a non- 
recursive entry from ABTERM. If so, the RB 
old PSW is restored from the field in which 
it was saved by ABTERM. If this entry is 
not through ABTERM and is nonrecursive, the 
completion code in register 1 is stored 
into the terminating task's TCB. At this 
time diagnostic information is also saved 
in the SVRB. 

ABENDO determines if SVC DUMP is in pro- 
gress. If so, all tasks that were set non- 
dispatchable by SVC DUMP are set dispatch- 



able and the Task Switch routine (IEA0DS02) 
is entered to switch tasks if necessary. 
The CVT lock bit is set off and GTF (if 
active) or the trace table (if present) is 
reactivated. If GTF was started, the stop 
count is reduced. 



For a first-time entry into ABEND, 
ABENDO issues the HOOK macro instruction to 
allow the Generalized Trace Facility (GTF) 
to determine if it is being terminated. If 
it is, it performs cleanup to prevent any 
resulting system damage. 



STAE/STAI INTERFACE ; ABENDO bypasses ASIR 
processing performed if any of the follow- 
ing conditions exist: 



• An ABEND recursion condition exists. 

• In a Model 65 Multiprocessing System, 
entry to ABEND was caused by the 
Machine-Check Handler of Recovery Mana- 
gement (indicated by TCBNSTAE field) to 
logically remove failing main storage 
(Storage Reconfiguration) . 

• No STAE environment exists. 

• The job-step timer expired for this 
task (except for the OLTEP task^) . 

• The operator issued a CANCEL command 
for this task (except for the OLTEP 
task) . 

• A STAE recursion exists, and there is 
no STAE control block for a STAI 
request. 

• A DETACH macro instruction was issued 
for a subtask that had not completed 
processing (completion code 13E) . This 
is not applicable for DETACH with STAE= 
YES (completion code 33E) . 

• All tasks in the job step are in a 30- 
minute wait (completion code 522) . 

• SYSOUT data exceeded the limit speci- 
fied by the OUTLIM parameter of the 
associated DO statement (completion 
code 722) . 

• Control was returned to ABENDO from 
ASIR2, specifying that no further STAI 
exits should be honored. 

• This task was previously terminating 
abnormally (close failure from a sub- 
task) . 



If any of these conditons exist, proces- 
sing continues with the Purge I/O routine. 



^Information on OLTEP tasks may be found in 
the publication Online Test Executive 
Program . 
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If the STAE address is present, bit one 
of the address field is tested for a Purge 
I/O with the QUIESCE option. If bit one is 
on, all SVRBs existing between the current 
SVRB and the Purge SVRB are forced through 
the Exit routine to remove them from their 
RB queues. The exit is accomplished by 
storing the address of SVC 3 in the right- 
half of the RBOPSW location of the SVRB. 
The Purge SVRB, which is also forced 
through the Exit routine, points to the 
previous ABEND'S SVRB (distinguished t^ the 
word 'ABENDO' in the extended save area). 
By removing all intervening SVRBs , control 
is returned to the RB level at which ASIR 
invoked Purge. ASIR then detects that the 
Purge routine has abnormally terminated, 
and takes appropriate action. 

If a STAE or STAI environment is in 
effect and none of these conditions exists, 
ABENDO passes control to ASIRO (IGCOROIC) 
to process the STAE/STAI. 

PURGING I/O ; If I/O operations are active 
at this time, another ABEND condition might 
occur as soon as ABEND next loses control 
to the system such as across the XCTL to 
the next load of ABEND. Any outstanding 
I/O could terminate abnormally, or hinder 
normal processing. The Purge I/O routine 
is entered at this time to avoid ABEND pro- 
cessing for a recursion resulting from an 
I/O abnormal termination. After this ini- 
tial ABEND, later ABEND processing of a 
valid recursion may also need to purge I/O. 
To accomplish this and avoid an ABEND/Purge 
loop, the Purge routine is skipped if both 
the ABEND bit (TCBFA) and the TCBREC flag 
indicate that an invalid recursion condi- 
tion exists. The ABEND bit is on, and the 
TCBREC flag is off. 

Before purging a first-time (nonrecur- 
sive) entry, an internal switch is set to 
indicate normal entry. The TCBFA bit is 
turned on, and the Purge routine is 
invoked. After the Purge routine has com- 
pleted processing, the internal switch is 
tested. If a normal, first-time entry 
exists, the TCBFA bit is turned off and 
ABEND processing continues. 

For a valid recursive entry, the intern- 
al switch is set to indicate this condi- 
tion. The TCBREC flag is turned off, the 
TCBFA bit is turned on, and the Purge rou- 
tine is invoked. If the internal switch 
(tested after Purge processing) indicates a 
valid recursion, the TCBREC flag is turned 
on prior to continuation of ABEND 
processing. 

The Purge routine is not supposed to be 
able to abnormally terminate; if it does, 
due to a system error, DAR should be 
entered to set the job step nondispatch- 
able. The TCBFA bit is turned on before 



calling the Purge routine to ensure that an 
abnormal termination condition will be 
treated as an invalid recursion. Control 
then passes to DAR without attempting 
another purge. 

DETERMINING IF TERMINAL ATTENTION EXIT ELE- 
MENTS (TAXE) ARE TO BE PURGE D: ABENDO 
determines from the TCBREC and TCBPTAXE 
flags in the TCBRECDE if this is a time 
sharing option (TSO) task and this entiry to 
ABEND is not due to a TAXE purge recursion. 
If so, the TAXE recursion flag (TCBPTAXE) 
flag is set and the routine lEAKJXP is 
entered to purge the TAXEs for the ter- 
minating TSO task. Upon return, the recur- 
sion configuration flag is turned off. 

CLEARING THE ABDUMP NONDISPATCHABILITY 
FLAG ; ABENDO clears the nondispatchability 
flag (TCBNDUMP) in the TCB and branches to 
the Task Switch routine for every task in 
the job step. ABDUMP may have previously 
set these flags to prevent alteration of 
dynamic queues during their display. 
ABENDO clears these flags so that the Dis- 
patcher may restart normal (non- 
terminating) tasks of the job step. 

The following example illustrates this 
point. Assume the normal task A has 
requested a dynamic dump of task B's 
resources. The ABDUMP routine, when it 
gets control, sets all tasks in the job 
step nondispatchable to prevent alteration 
of dynamic queues during the dump. While 
the dump is in progress and before the 
ABDUMP routine can reset nondispatchabili- 
ty, an error occurs that abnormally ter- 
minates task A. All tasks of the job step 
would remain nondispatchable if the ABENDO 
routine did not clear ABDUMP nondispatcha- 
bility soon after it gained control. 

EXITING FROM ABENDO ; If ABENDO had not 
been previously entered for this task (no 
recursion) or if this entry is a valid 
recursion, control passes to ABENDl. ASIRO 
(IGCOROIC) gains control if a valid STAE/ 
STAI or I/O purge recursion is present. 

Under the following conditions, exit 
from ABENDO is to DARl: 

• Invalid ABEND recursion. 

• Valid ABEND recursion in "must com- 
plete" status . 

• Valid or invalid DAR recursion. 

Processing during ABENDl (Entry Point 
IGCOIOIC) 

ABENDl performs the following functions: 

• Clears the "valid recursion" flags in 
the task's TCB. 
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• Recognizes whether a serious program 
error condition has occurred (such as a 
termination of a system task) . If such 
a condition exists, ABENDl passes con- 
trol to the Damage Assessment routine 
(DAR) via an XCTL macro instruction, 
after purging asynchronous exit queues 
(AEQs). 

• Defines the tree structure of the ter- 
minating task and performs housekeeping 
functions for the tasks in that tree. 

• Releases the program interruption ele- 
ment (PIE) if it exists. 

• Checks the validity of free queue ele- 
ments (FQEs) in the main storage queues 
of the tree structure of the termina- 
ting task to avoid recursions during 
later execution of the GETMAIN and 
FREEMAIN functions. 

• Purges those resources of the termina- 
ting task and its descendants that can 
operate asynchronously with those tasks 
and can cause needless processing dur- 
ing the course of the termination. The 
resources include unexpired timer 
intervals, I/O requests and I/O opera- 
tions that are in process, outstanding 
WTOR requests, and unscheduled requests 
for user (asynchronous) exit routines. 
When the Storage Reconfiguration bit is 
on in a Model 65 Multiprocessing sys- 
tem, ABENDl does not perform the I/O 
Purge and Timer Purge functions. 

• Converts ABEND to job- step ABEND if 
necessary. The entry to ABENDl is 
treated as a first-time entry after 
conversion. 

• Passes control to ABEND3 which tests 
for specific valid recursions and 
routes control accordingly via an XCTL 
macro instruction. 

ABENDl first clears the "valid recur- 
sion" flag in the TCB for the current task. 
The "valid recursion" flag (TCBREC), if set 
during a previous partial termination of 
the task, must be cleared so that ABENDl 
does not misinterpret as valid a future in- 
valid recursion. The only valid recursions 
are those which ABEND expects to be poss- 
ible, and which are handled via special 
ABEND processing. 

PROCESSING FOR A VALID RECURSION ; After 
determining that a valid recursion condi- 
tion exists, the next step is to purge 
recfuests for asynchronous exit routines 
that were possibly generated during the 
previous entry to the ABEND routine. Older 
requests of the same type, initiated by 
system or user programs of the task, were 
purged during earlier ABENDl execution. 



New queue elements which were created for 
ABEND- initiated functions such as OPEN, 
DUMP, or CLOSE, must be eliminated. This 
is done to prevent waste of system 
resources . 

ABENDl then passes control to ABENDS 
which eventually routes control for valid 
recursions. 

RECOGNIZING A SEVERE ERROR CONDITION ; 
After clearing the ABEND recursion flag 
(TCBREC) , ABENDl tests whether the current 
entry to the ABEND routine represents an 
error condition serious enough to warrant 
transfer of control to the Damage Assess- 
ment Routine (DAR) . The two conditions 
which ABEND may not be able to handle are: 

1. The attempted abnormal termination of 
any system task. 

2. The attempted abnormal termination of 
a task in "must complete" status. A 
task in "must complete" status must be 
completed for the system or step to 
remain intact. It should not be 
abnormally terminated. 

If such a condition exists, ABENDl flags 
the current task as the top task in the 
tree structure of terminating tasks and 
removes requests for asynchronous exit rou- 
tines before transferring control to the 
Damage Assessment Routine (DAR) . 

If neither of those conditions exists 
(as indicated by flags in the current TCB), 
ABENDl continues processing. 

PROCESSING FOR A FIRST-TIME ENTRY 

Determining the Scope of the Termination 
Request ; The termination request may be 
for a single task and its unterminated 
descendants or for the entire job step. 
The choice, an option of the ABEND macro 
instruction, is indicated in the input 
parameter list. The tree of tasks to be 
terminated originates with the current 
task, unless the STEP option has been spec- 
ified in the ABEND macro instruction. If 
the STEP option has been specified or if a 
conversion was made to a step ABEND for a 
subtask of the job step, the terminating 
tree of tasks must originate with the job- 
step task. 

An "alternate TCB" pointer is preloaded 
with the address of the job-step TCB, on 
the initial assumption that the caller has 
specified the STEP option or belongs to the 
job-step task. If the assumption is incor- 
rect, ABENDl places in the "alternate TCB" 
pointer, the address of the current or cal- 
ler's TCB. In this case, the "alternate 
TCB" pointer specifies the current task as 
the "top" task of the tree of tasks to be 
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terminated. The "top" or specified task 
and all its previously unterminated descen- 
dants are terminated during the course of 
ABEND processing. 

Setting Descendants Nondispatchable and 
Preventing Asynchronous Exits ; ABENDl sets 
nondispatchable all incomplete descendants 
of the specified task, and prevents asyn- 
chronous exits for these descendants. The 
main purpose is to avoid the possibility of 
a subtask gaining control during an I/O 
wait period and causing a new abnormal ter- 
mination. Such a new termination would be 
interpreted by ABENDO as an invalid recur- 
sion, and would cause an entry to DAR. A 
secondary pirrpose is to prevent the waste 
of system resources for subtasks that are 
planned for termination but are not yet 
terminated. 

To accomplish these objectives, and to 
indicate that the tasks of the tree are in 
the process of abnormal termination, ABENDl 
sets the following three flags in the TCB 
of each descendant; 

• "Abnormal wait" flag (TCBABWF) , which 
indicates to the Dispatcher that it may 
not place any routine of the task into 
execution. 

• "Prevent asynchronous exits" flag 
(TCBFX) , which indicates to the Stage 3 
Exit Effector that it may not transfer 
interruption queue elements from an 
asynchronous exit queue to a queue 
belonging to an IRB. It also prevents 
Stage 3 from queuing an IRB to a TCB, 
and thus prevents the scheduling of an 
asynchronous exit routine. 

• "Termination in process flag" (TCBFA) , 
which indicates to ABENDO, on later 
reentry for the same task, that a 
recursion has occurred. TCBFA is also 
an indicator to other system functions 
that an ABEND condition exists. 

To obtain the address of each TCB whose 
flags must be set, ABENDl uses a "task 
select" subroutine. This subroutine, used 
in various modules of the ABEND routine, 
and in the ABTERM and ABDUMP routines, 
scans the tree of TCBs whose tasks are to 
be terminated. It starts with the newest 
descendant of the "top" TCB- It then 
examines the tree of TCBs from the newest 
descendant to the top TCB. For each 
selected TCB, the three aforementioned 
flags are set. 

If the current TCB is being processed, 
the "abnormal wait flag" (TCBABWF) in the 
current TCB remains cleared, so that the 
next module of the ABEND routine may be 
dispatched for the current task when ABENDl 
is complete. The "top" flag (TCBFT) is 



also set in the TCB for the top or oldest 
task of the tree, to indicate to the ABEND 
routine that this task and all its incom- 
plete descendants are to be terminated. 

In a Model 65 Multiprocessing System, 
control is passed to the Task Removal rou- 
tine, which determines whether the current 
task on the second CPU has been set nondis- 
patchable. If it has, the second CPU is 
interrupted with an indication (in STMASK) 
that the Dispatcher must gain control. 

Checking the Validity of the Main Storage 
Queues ; ABENDl next checks the validity of 
the addresses of free queue elements 
(FQEs) , and checks the correctness of their 
length fields. It does this for all unpro- 
tected subpools belonging to or shared by 
the job step. Then it checks unprotected 
subpools of the task currently selected by 
the "task select" subroutine. (The "task 
select" subroutine selects in turn each 
task in the tree of tasks being ter- 
minated. ) The purpose of checking the FQEs 
is to prevent abnormal terminations , with 
resulting recursions to the ABEND routine, 
during the later use of the GETMAIN and 
FREEMAIN functions. 

Since FQEs are not in protected areas of 
main storage, they may be altered by a user 
program. When the GETMAIN or FREEMAIN rou- 
tine tries to gain access to an altered FQE 
to satisfy a request, the result is an 
ABEND. The need for the validity check of 
FQEs is thus apparent. 

ABENDl, via the MSSLOOP subroutine, 
scans the subpool queue for a selected 
task, searching for descriptor queue ele- 
ments (DQEs) . ABENDl examines all FQEs for 
each DQE for an owned subpool. It makes 
three general checks for each FQE: 

1. ABENDl first verifies that the free- 
area length specified in the FQE 
length field does not exceed the 
length described by the associated 
DQE. 

2. ABENDl next examines the validity of 
the free-area address in the FQE. It 
determines if the address specifies a 
location that is on a doubleword boun- 
dary, is within the bounds of main 
storage, and specifies a location that 
is in the area described by the asso- 
ciated DQE. 

3. As a last test, ABENDl verifies that 
the next FQE (pointed to by the FQE 
being examined) is at a lower main 
storage location than the FQE under 
examination. 

ABENDl nullifies the effect of an inval- 
id FQE by setting the FQE address to zero 
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in the DQE which describes the block. The 
entire space described by this DQE thus 
appears allocated. When all FQEs belonging 
to all subpool queue elements of the 
selected task have been examined (and 
altered if necessary), the validity check 
of the main storage queues is complete. 
After the check of main storage queues, 
ABENDl can safely purge the resources for 
the specified task. 

Purging Resources for the Specified Task 
and Its Descendants ; ABENDl (via separate 
routines) purges for the tree of tasks the 
program interruption element (PIE) if one 
has been specified, the timer queue, I/O 
requests and I/O operations in process, the 
WTOR queues, and the asynchronous exit 
queue for non-I/0 requests. Using the 
"task select" subroutine, and starting with 
the newest descendant task of the specified 
or "top" task, ABENDl purges the resources 
and resource requests for each task in the 
tree. During the scan of the tree of 
tasks, only resources belonging to pre- 
viously unterminated descendant tasks are 
released. Tasks that were previously ter- 
minated, either normally or abnormally as 
indicated by the "completion" flag (TCBFC) , 
are ignored and the next task is selected 
for FQE validity check and release of 
resources . 

Releasing the Program Interruption Element 
(PIE) ; ABENDl tests whether a program 
interruption element (PIE) exists for the 
task. (If a PIE exists, its address 
appears in the TCBPIE field of the TCB, 
placed there earlier when the SPIE routine 
created the program interruption element.) 
If the PIE exists, ABENDl branches to the 
FREEMAIN SVC routine to free the storage 
space. Subpool 250 is specified in the 
FREEMAIN parameter list to free subpool 0. 

Since an ABEND condition can occur while 
trying to free a PIE which was inadvertent- 
ly freed by the user, ABENDl sets the 
pointer to the PIE (TCBPIE) to zero and the 
PIE is conditionally freed. Any part of 
the PIE not freed now is released when the 
job step is terminated. 

Purging the Timer Queue ; The first group 
of resource requests to be purged for each 
task is contained in the timer queue. The 
Timer Purge routine removes from the timer 
queue those elements that represent unex- 
pired timer requests for the task. It also 
frees the space occupied by these elements. 
The purpose is to minimize the number of 
external interruptions for tasks that are 
terminating. The Timer Purge routine also 
frees the problem program register save 
area associated with each user (asynchro- 
nous) exit routine. (The associated save 
area is pointed to by its TQE. ) Before 
ABENDl branches to the Timer Purge routine. 



it sets the valid recursion flag TCBREC. 
This flag stays on when the Timer Purge 
routine enters the TAXE Purge routine via a 
branch and link. A TAXE purge of all 
tasks in the terminating tree (except the 
current task which was purged earlier) is 
performed at this time. 

Purging I/O Requests and I/O Operations in 
Process ; ABENDl purges I/O requests and 
I/O operations to avoid errors that can 
cause recursion to the ABEND routine. 
Since the ABEND routine frees main storage, 
an I/O operation that is not halted can 
cause information to be read into main 
storage that may have been reallocated. 
This could cause data or programs to be 
destroyed. Furthermore, an event control 
block may be posted in reallocated main 
storage, thus causing an additional error. 
ABENDl removes (via the SVC Purge routine) 
I/O requests (RQEs) that have not yet been 
serviced. By Halt I/O instructions, the 
SVC Purge routine stops I/O operations in 
process for each task of the tree. RQEs 
removed from the request queue are returned 
to a list of available RQEs for reuse by 
the I/O supervisor. Besides purging I/O 
operations in process and outstanding I/O 
requests, the SVC Purge routine dequeues, 
from the SIRB, elements representing sche- 
duled requests for the use of I/O error 
handling routines. 

Purging the Operator Communication Queues ; 
After removing I/O requests and halting 
current I/O operations for a task, ABENDl 
branches to the resident WTOR Purge rou- 
tine. This routine removes elements from 
the buffer queue and from the reply queue 
that represent both messages to the opera- 
tor and the operator's replies associated 
with the terminating task. The purpose of 
purging these elements from the queues is 
threefold: to save processing time, to 
prevent errors, and to prevent posting of 
meaningless ECBs for the communications 
task. These ECBs may not exist after 
ABEND16 frees dynamically acquired main 
storage. 

Removing Requests for User (Asynchronous) 
Exit Routines ; After purging the operator 
communication queues, ABENDl branches to 
another subroutine to remove asynchronous 
exit requests. Those IQEs on the asynchro- 
nous exit queue that represent exit 
requests for the terminating task are 
dequeued. The elements are freed later 
during ABENDl 6 when subpools of main 
storage are released. Note that IQEs are 
removed from the asynchronous exit queue 
but not from an IRB's queue if they have 
already been scheduled by the Stage 3 Exit 
Effector. The purpose of removing the IQEs 
from the queue is to minimize the schedu- 
ling of asynchronous exit routines that can 
occur after the "prevent asynchronous 
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exits" flag is cleared at the end of 
ABENDS. The execution of an asynchronous 
exit routine, before ABEND processing is 
complete, can cause an invalid recursion if 
the Exit routine abnormally terminates. 
Such execution can also slow up the ter- 
mination processing. After the TCBFX flag 
is cleared, the Stage 3 Exit Effector can 
schedule asynchronous exit routines for 
system functions that may be needed during 
I/O operations for Open, Close, and ABDUMP 
processing. (See "Scheduling of User Exit 
Routines" in Section 3, "Task 
Supervision. ") 



Processing during ABEND3 (Entry Point 
IGC0301C) 

ABEND3 performs the following main 
functions : 



• Removes from the job pack area queue 
one or more contents directory entries 
(CDEs) , which represent the partially 
loaded module, and frees the space they 
occupy. 

• If there are other requesters which are 
awaiting the loading of the module, 
prepares one or more RBs for reentry to 
Contents Supervision (lEAQLKOO) at 
CDCONTRL to refetch the module for 
another task. 

The PARRLSE routine searches the job 
pack area queue for CDEs whose modules are 
in the process of being loaded for a termi- 
nating task. (The CDENIC flag was set in 
each CDE whose module is being loaded.) 
Each CDE whose module is being loaded is 
purged if either of two requirements is 
met: 



• Releases partially loaded modules. 

• For any recursion other than a type-1 
message recursion, ABENDS purges any 
entries in the information list for the 
TCB that just terminated. 

• Allows asynchronous exits. 

• Routes valid recursions. 



RELEASING PARTIALLY LOADED MODULES: 



ABENDS 



releases "partially loaded" modules for 
terminating tasks. Such modules are in the 
process of being loaded for the current 
task or for other tasks that are being 
abnormally terminated (TCBABWF flag set) . 

When a task is set permanently nondis- 
patchable (TCBABWF flag set), the Contents 
Supervision routines do not complete the 
loading of a module requested for the task. 
The routines also do not begin a new fetch 
of a module whose loading process has 
started. Other requesters waiting for the 
module cannot gain access to it. Of pri- 
mary interest are the modules containing 
the ABDUMP and BSAM routines, needed by 
ABENDS and ABEND9. These modules may have 
been requested by a subtask of a task that 
is now terminating. Since ABENDl may have 
placed the subtask in the abnormal wait 
state (TCBABWF flag set) , the routines may 
be permanently unavailable. The problem of 
"frozen" partially loaded modules is solved 
by the "release" routine of ABENDS, called 
PARRLSE. 

For each module in process of being 
loaded for a terminating task, the PARRLSE 
routine perfoinns the following purge 
functions: 



• The loading was initiated for the cur- 
rent task. In this case, the current 
task is being terminated and its I/O 
operations have already been purged by 
ABEND 0. 

• The loading was initiated for another 
task which is being abnormally ter- 
minated and is nondispatchable (TCBABWF 
flag set), and whose I/O operations, 
initiated for loading, have already 
been purged by ABENDl (TCBFA flag set). 

The CDE, its extent list, and program 
area may not be freed until the task's I/O 
operations have been purged by ABENDl. 
Otherwise, the Main Storage Supervision 
routines may reallocate the freed program 
area for another task. The requested 
module may later arrive in main storage, 
overlaying the reallocated program area, 
which now belongs to another task. 



PURGING TYPE-1 MESSAGES ON RECURSION: 



On 



recursive entry to ABEND for any recursion 
other than the type-1 message recursion, a 
new entry might have been made in the list 
as part of the recursion. Therefore, 
ABENDS purges any entries in the type-1 
information list which are for the TCB that 
recursively terminated. 



DECIDING THE NEXT PART OF -ABEND TO BE 
INVOKED : After allowing the scheduling of 
I/O exit routines, ABENDS determines which 
part of the ABEND routine it should invoke: 

• ABEND4 - current entry is a first-time 
entry, or a type-1 message WTP 
recursion. 



• Frees the module's program area and, if 
this is not a job-step task, the extent 
list. 



ABEND? - recursion due to an error in 
the Graphics Debug routine, or in clos- 
ing the Direct SYSOUT data set. 
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• ABENDS - recursion due to a failure in 
the Open routine. 

• ABEND9 - recursion due to an error 
detected in the ABDUMP routine. 

• ABENDll - recursion due to an error in 
the Close routine. 

• ABEND13 - given control if any other 
valid recursions are indicated in the 
TCBRECDE field. 



Processing during ABEND4 (Entry Point 
IGCOtOlC) 

ABEND 4 has three main purposes: 

• Write type-1 SVC messages. 

• Purge message list entries. 

• Free type-1 message WTP buffers. 

WRITE TYPE 1-SVC MESSAGES ; Type-1 SVC rou- 
tines run in a disabled state and thus are 
unable to issue WTP messages as a result of 
an abnormal termination. Instead, a mes- 
sage information list is maintained in the 
nucleus in which type-1 SVC routines can 
store data. The list is located by a 
pointer in the CVTQMSGA field of the CVT- 

If the entry to ABENDU is a message 
recursion (the TCBTYPIW flag is set) , pro- 
cessing continues with the purging of mes- 
sage list entries. Otherwise, a check is 
made for an unprocessed entry in the mes- 
sage information list for the currently 
terminating task's TCB. If an entry is 
present, a conditional GETMAIN is issued to 
obtain storage from which to write mes- 
sages. If the fifth word in the extended 
save area (ESA) is zero, there is no 
storage available to fulfill the GETMAIN 
request. No message list elements are for- 
matted, and processing continues with the 
purging of the list elements. 

If storage is available, the fifth word 
in the ESA contains the address of the 
storage area allocated for the WTP buffer. 
ABEND4 formats the list elements to be 
written. The following items are placed 
into the message: 

• Reason code 

• Job name or branch address if the rou- 
tine causing the ABEND condition was 
entered via a branch entry 

• Step name 

• Flag characters 

• Message text (maximum of 16 bytes) 



After formatting has been completed, the 
descriptor, routing codes, and message 
recursion flags are set. A WTO macro 
instruction is then issued to write the 
message. After the message has been writ- 
ten, the valid recursion flags (TCBRECDE) 
are turned off, and any remaining list 
entries are processed. 

PURGING OF MESSAGE LIST' ELEMENTS : When all 
messages have been written, a check is made 
of the information list for entries corres- 
ponding to other tasks in the terminating 
tree. Such entries are purged so the ele- 
ments can be used again. 

FREEING OF TYPE-1 SVC MESSAGE WTP BUFFERS : 
A lower level task may have terminated ear- 
lier which was processing a type-1 SVC mes- 
sage for that task when the current ABEND 
condition occurred. If so, a previous 
entry into ABEND4 may have already obtained 
storage for a WTP buffer. ABEND4 checks 
the fifth word in the ESA for a storage 
address- If there is a buffer for any task 
in the terminating tree, it is freed. 

EXITING FROM ABENDt ; When all entries have 
been purged, ABENDU determines where to 
route control, and issues an XCTL instruc- 
tion to the proper module. If the rollout/ 
rollin feature is in the system, ABENDS 
gains control. Otherwise, ABEND? receives 
control if a dump was requested, and 
ABENDll if it was not. 



Processing during ABENDS (Entry Point 
IGCOSOIC) 

The main purpose of ABENDS processing is 
to purge queues related to the rollout/ 
rollin feature. The Rollout Purge routine 
(ROLLPRG) is an internal routine used to 
remove the appropriate IQEs from the rol- 
lout queues. 

When a request for rollout cannot be 
satisfied, the IQE representing that re- 
quest may be added on a FIFO basis to a 
queue to defer the request until a later 
time when it can be satisfied. While a 
task has an IQE on the rollout queue 
(lEAROQUE) , it is set nondispatchable. It 
may be abnormally terminated, however, and 
the IQE must be removed from the rollout 
queue because the task no longer needs the 
rollout request. This abnormal termination 
may be the result of issuing the CANCEL 
command, a time expiration, or a higher 
level task ABEND. 

REMOVING IQES FROM THEIR QUEUES ; IQEs are 
removed from the rollout queue and from the 
asynchronous exit queue by the Rollout 
Purge routine. Input to this routine con- 
sists successively of the address of each 
TCB in the terminating task tree. 
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IQEs on the rollout queue are examined 
first. If the TCB address in the first 
word of the parameter list addressed by an 
IQE on the rollout queue is equal to the 
TCB address passed to this routine, the 
count of queued rollout requests is decre- 
mented by one, and the IQE is removed from 
the queue and returned to the available 
list (whose origin is the rollout IRB) . 

If a TCB match is not made against an 
IQE on the rollout queue, or if the queue 
is empty, IQEs on the asynchronous exit 
queue (AEQE) are examined. If a match is 
made against the TCB address in the para- 
meter list addressed by an IQE on this 
queue, the IQE is removed from the queue 
and returned to the available list. 

If no match is obtained against an IQE 
on the AEQE or if the queue is empty, the 
queue of IQEs originating from the rollout 
IRB is examined. If a match is obtained 
against the TCB address in the parameter 
list addressed by an IQE on this queue, and 
the IQE is not at the head of the queue 
(not addressed by the RBIQE field and 
therefore not currently being processed by 
Rollout) , the IQE is removed from the queue 
and returned to the available list. If a 
match is made and the IQE is at the head of 
the queue (currently being processed by 
Rollout) , a flag is set in the parameter 
list addressed by the IQE to indicate to 
the Rollout routine that the task is in the 
process of terminating abnormally. 

EXITING FROM ABENDS ; ABENDS passes control 
to ABEND7 if a dump is requested and 
allowed. Otherwise exit is to ABENDll. 

Processing during ABEND7 (Entry Point 
IGC0701C) 

ABEND? is entered only if an ABEND dump 
is requested and allowed. It does any 
feature-dependent processing necessary 
prior to the opening of the dump data set. 
The two main functions are: 

• Processing for graphics jobs. 

• Closing the Direct SYSOUT Writer if it 
has been started to tape. 

PROCESSING FOR GRAPHICS JOBS ; The Graphics 
Debug routine is entered for foreground 
jobs and the Graphics Job Processor. It is 
not entered for a Storage Reconfiguration 
ABEND condition. For a graphics recursion, 
the recursion flag is turned off, and con- 
trol passes to the routine that checks for 
a Direct SYSOUT Writer. 

Before calling the Graphics Debug rou- 
tine, ABEND7 checks whether a dump is 
allowed for the terminating task. If a 
dump is allowed, a GETMAIN macro instruc- 



tion is issued to test if there is suffi- 
cient storage available in subpool 252 for 
ABDOMP's resident module, lEAQADOA. If 
there is either insufficient storage or a 
dump is not permitted, a parameter is 
passed to the Graphics routine indicating 
that the user may not request a dump. 



In the event of a successful GETMAIN re- 
quest, a FREEMAIN macro instruction is 
issued to free the storage. The parameter 
passed to the Graphics routine indicates 
that a dump is available to the user. 



ABEND7 then turns on the recursion con- 
figuration flags and passes control to the 
Graphics Debug routine. If the dump para- 
meter is on, the user has the option of 
accepting or bypassing the dump. The 
Graphics routine queries the user, sets the 
parameter to indicate the user response, 
and returns to ABEND7. If the dump is 
requested, ABEND7 processing continues. If 
the user indicated that he wished to bypass 
the dump, ABEND7 turns off the high-order 
bit of the completion code field in the TCB 
and issues an XCTL to ABENDll. 



DETERMINING IF A DIRECT SYSOOT WRITER HAS 
BEEN STARTED ; If a dump is requested, 
ABEND7 tests to determine if the SYSUDUMP/ 
SYSABEND diamp data set is allocated to a 
tape device to which a Direct SYSOUT Writer 
has been started. 



If the dump is requested for a subtask 
ABEND, the dump is bypassed to prevent a 
later attempt to use the tape device. Such 
an attempt would cause another ABEND. The 
ABEND dump data set remains open for the 
entire job step. Thus if a subtask were 
allowed to take a dump, the direct SYSOUT 
device would remain open needlessly for the 
entire job step. Any other user attempting 
to use the direct SYSOUT device, even after 
the subtask had completed, would be unable 
to do so. 

If the dump is requested for a job-step 
ABEND, and the SYSOUT data set is already 
open for the user requesting the dump, the 
SYSOUT data set is closed so that it can be 
reopened as an ABEND dump data set. After 
ABEND9 processing has completed, ABENDll 
closes the data set. 

If a recursion occurs when attempting to 
close the SYSOUT data set, the "prevent 
dump" indicator (TCBPDUMP) is set, and 
ABEND7 exits. ABEND7 passes control via an 
XCTL to (1) ABENDS if a dump is requested 
and can be given at this point, or (2) 
ABENDll if the dump is not requested or 
must be bypassed. 
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Processing during ABENDS (Entry Point 
IGC0801C) 

ABENDS processing deals with the follow- 
ing diimp-related functions: 

• Processing for recursive entry due to 
an open failure. 

• Determining if the "prevent dump" indi- 
cator is set. 

• Determining if there is a dump data set 
to be opened. 

• Determining if the dump data set is 
already open. 

• Opening the data set. 

• Ensuring that the dump data set remain 
open for the duration of the job step. 

• Indicating if the dump data set has 
been opened. 



DETERMINING IF THE ENTRY TO ABENDS IS DUE 
TO RECURSION ; If the entry to ABENDS is 
due to recursion, the TCBREC and TCBOPEN 
configuration flags were set in the current 
TCB by previous ABENDS processing. A pre- 
vious execution of the Open routine of data 
management for this task produced an error. 
The error caused a reentry to the ABEND 
routine. Since the previous attempt to 
open the dump data set for the current task 
failed, ABENDS does not try again. Instead 
it performs the following functions: 

• Resets the Open recursion indicators in 
the current task. 

• Locates the previous SVRB under which 
ABENDS was operating, and extracts the 
saved load list elements and TCBMSS 
pointer. 



Indicates an internal 
condition . 



"no dump now" 



• Updates the load list queue on the cur- 
rent TCB. 

• Restores the current TCBMSS pointer and 
sets non-terminating tasks of the job 
step dispatchable. 

• Passes control, via an XCTL, to 
ABENDll . 

DETERMINING IF THE "PREVENT DUMP" INDICATOR 
IS SET ; If the entry is not a recursion, 
ABENDS next tests if the "prevent dump" 
indicator (TCBPDUMP) is set in the job- step 
TCB. The indicator may have been set at 
this time because of a Direct SYSOUT recur- 
sion. This indicator may also be set at a 



later point in ABEND processing for either 
of the following two conditions; 

• "Steal core" situation exists. 

• The "dump data set open" bit is on, but 
the data set cannot be found. This is 
the result of a dump data set which was 
opened (thus accounting for the bit 
setting) , but later reclosed as part of 
Normal Termination for the job- step 
task, which then terminated abnoinmally. 
Because the close occurred before 
ABENDS gained control, ABENDS searches 
for the dump data set which it is 
unable to locate. 

If the "prevent dump" indicator is set, 
ABENDS cannot prepare for dumps. It there- 
fore bypasses the rest of its processing 
and passes control to ABENDll to close the 
data sets used by the terminating tasks - 



DETERMINING IF THE DUMP DATA SET IS TO BE 
OPENED: ABENDS performs tests to determine 
if it should open the dump data set (SYS- 
ABEND or SYSUDUMP) for use during ABEND9. 
These tests determine: 

• Whether the caller of the ABEND routine 
has requested a dump. 

• Whether the SYSUDUMP data set was allo- 
cated by means of a DD card. 

• Whether the SYSABEND data set was allo- 
cated by means of a DD card- 

• Whether the dump data set was previous- 
ly opened for another task in the job 
step. 



TESTING THE DUMP REQUEST AND THE STATUS OF 
THE DUMP DATA SET : ABENDS makes three 
tests to determine whether it should open 
the dump data set, or whether it should 
invoke ABEND9 or ABENDll immediately. Two 
of these tests check whether a dump cannot 
or should not occur. The third test deter- 
mines if the dump data set has already been 
opened for another task of the job step. 

One test determines if a dump was 
requested by the caller of the ABEND rou- 
tine. ABENDS tests the high-order bit of 
the completion code in the TCBCMP field of 
the current TCB. If the caller did not re- 
quest a dump, or if neither data set was 
allocated, ABENDS invokes ABENDll. 

Another test examines the task I/O table 
(TIOT) to determine if a SYSABEND or SYS- 
UDUMP DD card was recognized by the Reader/ 
Interpreter of the Job Scheduler, and thus 
whether the SYSABEND or SYSUDUMP data set 
was allocated by the Job Scheduler. 
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The remaining test determines if the 
dump data set (SYSABEND or SYSUDUMP) has 
already been opened for another task of the 
job step, and therefore if the Open func- 
tion may be bypassed. (The test checks the 
TCBFDSOP flag in the job- step TCB.) 

The DD card could be missing now, but 
defined later if dynamic device allocation 
is being used. In this case, ABENDS skips 
the dump now, but allows an ABEND dump of a 
future terminating task. 

DETERMINING IF THE DUMP DATA SET IS AUIEADY 
OPEN ; If the dump data set was previously 
opened, ABENDS obtains the DCB address by 
searching the DEB queue of the job-step 
task for the DEB belonging to the data set. 
(When opening the dump data set originally, 
ABENDS located the DEB belonging to the 
data set and set a special identifier. ) It 
then extracts the DCB address from the DEB 
for use during I/O operations of the dump 
procedure of ABEND9. After obtaining the 
DCB address, ABENDS passes control to 
ABEND9 to take the dump. 

It is possible that the dump data set 
was previously opened but is no longer on 
the DEB chain. Consider the following 
case: The dump data set was previously 
opened for an abnormally terminating sub- 
task of the job step. Then it was closed 
in normal termination for the job step. 
Subsequently, the job step was abnormally 
terminated. The dump data set cannot be 
reopened because that would overlay infor- 
mation in the dump for the subtask. In 
this case, ABENDS sets on the prevent dump 
indicator and passes control to ABEND9. 

OPENING THE DUMP DATA SET ; After all tests 
have been made to ensure that the dump data 
set should be opened, ABENDS performs the 
necessary Open functions. The field in the 
extended save area in which the load list 
pointer will be saved after the GETMAIN for 
the DCB must be zeroed out. This pointer 
is added to the present load list chain if 
the GETMAIN fails and there is a recursion. 
If this were not done, there would be an 
invalid recursion later when ABENDS 
attempts to free the load list. 

All tasks (except the current task) in 
the task tree of the job step are set non- 
dispatchable, and the TCBMSS pointer for 
the current task is saved in the extended 
save area. The TCBMSS pointer from the job 
step TCB is put into the TCBMSS field of 
the current task. This ensures that the 
lOBs for the dump data set will come from 
the job- step task's subpool 0. 

ABENDS issues a GETMAIN macro instruc- 
tion to obtain storage for the DCB, which 
is then moved into the newly acquired area. 
The ABEND dump data set is then opened to 



perform one of two dumping functions. One 
of two DD cards may be specified for the 
ABEND dump data set. Although both may be 
specified in a JCL procedure, the first one 
found in the TIOT is used across the job 
step. For a SYSABEND DD card, a dump of 
the nucleus, control blocks, and job-step 
region is given. A SYSDDUMP DD card 
results in a dump of only the control 
blocks and job-step region. 

ENSURING THAT THE DUMP DATA SET REMAINS 
OPEN ; Both before issuing the OPEN macro 
instruction, and after the execution of the 
Open routine (if the open request has been 
successful) , ABENDS tries to ensure that 
the dump data set remains "open" for the 
remainder of the job step. "Open" means 
the retention of BSAM access method rou- 
tines in main storage, and the retention of 
the DEB and DCB for the dump data set. 
Special efforts are needed to keep the dump 
data set open, since ABENDll closes data 
sets belonging to the terminating tree of 
tasks, and ABEND16 frees the load lists 
belonging to these tasks and the associated 
program areas (if there are no outstanding 
requests for the programs) . Unless special 
precautions are taken, the DEB for the dump 
data set is removed and freed from its DEB 
list during ABENDll, and the BSAM routines 
possibly released during ABEND16. With the 
dump data set no longer "open" , further 
abnormal dumps during the remaining life of 
the job step would not be possible. 
Repeated opening of the data set, after it 
has been initially opened, is avoided for 
two reasons : such repetition would waste 
time, and each reissue of the OPEN macro 
instruction (if acted upon) could possibly 
reposition the data set volume undesirably 
(depending on the DISP operand of the 
user's DD card — see Job Control Language 
Reference publication) . 

ABENDS does two things to preserve the 
"open" status of the dump data set: 

1. It prevents the deletion of the BSAM 
routines by forcing the creation of 
new load list elements for them. It 
queues the new load list element to 
the load list for the job- step TCB. 

2. It places the DEB for the dump data 
set on the DEB queue belonging to the 
job-step TCB. 

ABENDS prevents deletion of the BSAM 
routines from main storage by saving the 
load list pointer (TCBLLS) for the current 
task and replacing the pointer with zeros. 
When ABENDS issues the OPEN macro instruc- 
tion, the Open routine requests the loading 
of the BSAM module. Since the Contents 
Supervision routines cannot find load list 
elements representing the BSAM routines on 
the current task's load list (the zeroed 
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load list pointer indicates that there is 
no load list) , they create new load list 
elements for the BSAM routines, and place 
the load list pointer (TCBLLS) in the cur- 
rent TCB. New CDES are not created if the 
BSAM routines are already in main storage. 
After ABENDS issues the OPEN macro instruc- 
tion, it places the newly created load list 
elements for BSAM on the load list belong- 
ing to the job-step TCB. Thereafter, the 
BSAM routines cannot be deleted from main 
storage by the Close routine of data mana- 
gement, until data sets belonging to the 
job-step TCB are closed at normal or 
abnormal step termination. ABENDS then 
issues the OPEN macro instruction. Regard- 
less of whether the data set is actually 
"opened," ABENDS restores the original load 
list pointer (TCBLLS) to the current TCB. 
If a recursive entry to the ABEND routine 
occurs because of an error during the 
execution of the Open routine, the load 
list pointer is also restored. 

If the open attempt is successful (as 
indicated by a flag in the DCB of the dump 
data set) , ABENDS uniquely labels the data 
extent block (DEB) associated with the dump 
data set so that it can later find the DEB, 
and obtain from it the associated DCB 
address. ABENDS passes the DCB address to 
ABEND9. The position of the DEB in the DEB 
queue can vary because of processing by the 
End-of -Volume (EOV) data management rou- 
tine. 

ABENDS then places the DEB on the job- 
step task's DEB queue. It does this to 
prevent ABENDll from closing the dump data 
set, when it closes data sets belonging to 
the terminating tree of tasks. 

INDICATING IF THE DUMP DATA SET HAS BEEN 
OPENED: When the request to open the dump 
data set has been issued and the Open rou- 
tine of data management has been executed, 
ABENDS tests the appropriate flag of the 
DCB to learn if the data set has been actu- 
ally opened. According to the results of 
the test, ABENDS indicates, via a flag bit 
in the job-step TCB if the open request has 
been successful. 



TCBREC) in the current TCB. It does this 
to indicate that any new recursion is not 
due to open processing and is invalid. 

CONCLUSION OF ABENDS ; ABENDS processing is 
completed according to the results of tests 
already described in the topic "Determining 
if the Dump Data Set is to be Opened." 
Control passes to ABEND9 for dump proces- 
sing or, if no dump is required, to 
ABENDll. 

Processing during ABEND9 
(Entry Point IGC0901C) 

ABEND9 performs ABDUMP processing. This 
includes the dump of resources belonging to 
the terminating tasks of the tree (that is, 
the specified task and its descendants) . 

ABEND9 uses a number of SVC routines to 
perform its functions. Of primary impor- 
tance are the ABDUMP routines. For each 
invocation, ABDUMP displays the resources 
of the selected task. ABEND9 invokes the 
ABDUMP routine separately for the "top" 
task, its descendants, and its direct 
ancestors. 

There are two types of entries to 
ABEND9: first-time entries and recursive 
entries. A first-time entry represents a 
first-time request for the abnormal ter- 
mination of a task. It occurs via an XCTL 
macro instruction from ABENDS. A recursive 
entry represents a request for abnormal 
termination generated by ABDUMP because of 
an error detected during its processing. A 
recursive entry to ABEND9 is always made 
directly from ABENDS, via an XCTL macro 
instruction. 

The scope of ABEND9 processing varies, 
depending on the particular type of entry. 
A first-time entry permits ABEND9 to per- 
form the dump function. A recursion 
because of an ABDUMP error causes the 
bypassing of the dump function, but permits 
ABDUMP-related cleanup functions to be per- 
formed. A Storage Reconfiguration ABEND 
also causes the bypassing of the dump 
function. 



If the data set could not be opened, and 
therefore abnormal dumps are not possible, 
ABENDS passes control to ABENDll. 

If the dump data set was actually 
opened, ABENDS sets an indicator in the 
job- step TCB. It sets the "data set open" 
indicator (TCBFDSOP) so that in a later 
ABEND within the job step, it may bypass 
much of ABENDS processing and invoke 
ABEND 9 . 

Regardless of whether the dump data set 
could be opened, ABENDS clears the "open" 
and "recursion" indicators (TCBOPEN and 



DETERMINING THE SCOPE OF PROCESSING ; 
Before ABEND9 can perform any of its major 
functions, it must test certain indicators 
to learn the type of processing that it 
must perform. It first tests for a recur- 
sion because of an error during ABDUMP pro- 
cessing (the ABDUMP routine can request a 
reentry to ABEND if it discovers an error) . 

If a recursion has occurred from the 
ABDUMP routine (as indicated by the "set" 
condition of the "ABDUMP recursion" confi- 
guration flag TCBADUMP in the current TCB) , 
ABEND9 issues a DEQ macro instruction spe- 
cifying the dump data set. 
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If no recursion from the ABDUMP routine 
has occurred, ABEND9 makes two other tests 
before performing ABDUMP processing. 
Either of these tests can cause the bypas- 
sing of ABDUMP processing. The first test 
examines the "prevent dump" indicator 
(TCBPDUMP) in the job-step TCB to learn if 
ABEND? or ABENDS had discovered an abnormal 
condition. ABEND7 sets the indicator if 
there was a Direct SYSOUT Close failure. 
ABENDS sets the indicator if the dump data 
set was closed by normal termination of the 
job-step task. 

If the "prevent dump" indicator is not 
set, ABEND9 tests the DCB address passed by 
ABENDS in a register. If the address is 
zero, the caller of the ABEND routine has 
not requested a dump. Accordingly, ABEND9 
bypasses the ABDUMP processing and passes 
control, via an XCTL, to ABENDll. But if 
the address is not zero, the DCB register 
contains the address of the DCB that ABENDS 
used to open the dump data set. 

If the "prevent-dump" indicator is set, 
or if the DCB address is zero, dumps for 
the current tree of terminating tasks are 
bypassed. There is, however, an important 
distinction between the meaning of the two 
indicators. If the DCB address is zero, 
abnormal dumps are bypassed only for the 
processing of the current ABEND request, 
since the ABEND routine's caller has not 
requested dumps or the Open or previous 
dump failed for the terminating task tree. 
The error condition might be corrected by 
successful termination of this tree (if 
there was not enough main storage avail- 
able) . Therefore, a later dump could be 
possible. But if the "prevent dump" indi- 
cator is set, no abnormal dump will be per- 
formed for the remainder of the current job 
step, since a permanent error exists. 

For Storage Reconfiguration, the "pre- 
vent dump" has already been set as a result 
of Machine-Check Handler processing. 

If the "prevent dump" indicator is not 
set, and the DCB address passed to ABEND9 
is not zero, ABDUMP processing is performed 
as described in the following section. 

PERFORMING ABDUMP PROCESSING ; The ABDUMP 
processing consists of three functional 
parts: preparation for the dumps, perfor- 
mance of the dumps, and a cleanup procedure 
after the dumps. 

Preparation for the Dumps ; Before ABEND9 
can issue a SNAP macro instruction to 
invoke ABDUMP for each task to be dumped, 
it must take certain precautions. To pre- 
vent repetitious loading, it ensures that 
the ABDUMP routine's "resident" module 
(lEAQADOA) remains in main storage through- 
out the series of dumps for the current 



task, its descendants, and its ancestors. 
Otherwise, the ABDUMP routine would load 
its resident module before each dump, and 
delete the module after each dump. ABEND9 
issues a LOAD macro instruction to load the 
resident module before it invokes the 
ABDUMP routine for the first task, and 
deletes the module after the ABDUMP routine 
has been executed for the last task of the 
tree. ABEND9 thus prevents the actual 
reloading and deletion of the resident 
module by the ABDUMP routine each time that 
it is entered. (Although the ABDUMP rou- 
tine issues a LOAD macro instruction to 
load the resident module, no loading occurs 
since the module is already in main 
storage.) 



As another precaution, ABEND9 ensures 
that the dumps associated with one ABEND 
request will appear consecutively on the 
dump data set, not interspersed with dumps 
for a concurrently terminating tree in the 
same job step. To prevent such interleaved 
dumps, ABEND9 issues an ENQ macro instruc- 
tion (with the "exclusive" option) for the 
dump data resource set before the first 
ABDUMP execution and issues a DEQ macro 
instruction after the last ABDUMP 
execution. 

The ENQ routine, besides its normal pro- 
cessing, performs a special service for 
ABEND9. It makes possible the servicing of 
the currently issued ENQ request for the 
dump data set. Such action is necessary if 
a subtask of the current task was previous- 
ly abnormally terminated. The data set may 
still be enqueued for the previously 
requested dump of the subtask* s resources. 
In this case, the servicing of the current 
ENQ request would await the issuance of a 
DEQ macro instruction by ABEND9, when the 
dump of the subtask' s resources is com- 
plete. But since the subtask is now non- 
dispatchable (its TCBABWF flag set during 
ABENDl) , the DEQ macro instruction cannot 
be issued by ABEND9 for the subtask. 

When the ENQ routine detects that the 
ABEND routine is the caller, it removes 
from the resource queues, via its "auto- 
purge" subroutine, all queue elements for 
that resource belonging to the top ter- 
minating task and any of its subtasks. The 
current ENQ request issued by ABEND9 can 
then be serviced. 



Performing the Dumps ; Dumps of the ter- 
minating tasks of the tree are made if the 
following conditions have been met, tested 
by both ABENDS and ABEND9; 

1. A dump data set has been provided (as 
indicated by a search of the TIOT by 
ABENDS). 
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2. A preassembled DCB can be opened (also 
by ABENDS) . 

3. The caller of ABEND has requested 
dumps. 

If the user has provided a SYSABEND DD 
statement, and if GTF is active to format 
(in internal mode), GTF is suspended for 
the dump by issuing a HOOK macro instruc- 
tion. This stops GTF trace entries until 
the trace is dumped; 

Via issuance of the SNAP macro instruc- 
tion (SVC 51), ABEND9 invokes the ABDUMP 
routine separately for each task whose 
resources are to be displayed. The current 
task is dumped first, then its descendants, 
then its direct ancestors, including the 
job-step task (see Figure 10-8). 

Each task of the tree of tasks (D, G, 
and F in Figure 10-8) is selected by means 
of the "task select" (TASKSEL) subroutine. 
As each task is selected by the subroutine, 
ABEND9 tests the "S" flag (TCBFS) in its 
TCB to determine if the task's resources 
have already been dumped. If the "S" flag 
is set, the resources have already been 
dumped, and the next task is selected. For 
each task that has not already been dinnped, 
ABEND9 issues a SNAP macro instruction (SVC 
51) to dump the task's resources. The 
operands of the macro instruction include 
the address of the selected TCB, the DCB 
address received from ABENDS, and the fact 
that the ABEND routine is the caller (via a 
bit that is set in the ABDUMP parameter 
list provided by ABEND in its SVRB ESA. On 
each return of control from the ABDUMP rou- 
tine for a subtask, ABEND9 sets the "S" 
flag in the subtask TCB to indicate that 
the subtask' s resources have been dumped. 

The ABDUMP routine displays for the cur- 
rent task the following resources: job 
name, step name, date, time, completion 
code, PSW at entry to ABEND, TCB, RBs, load 
list, CDEs, extent lists, TIOT, DEBs, 
SPQEs, DQEs, FQEs, PQEs, FBQEs, save area 
trace, QCBs, address of the last point of 
interruption (old PSW) , register contents 
at entjry to ABEND, the nucleus (skipped if 
the DD card was the SYSDDUMP) , load 
modules, and the subpool blocks. If GTF is 
active and in internal mode, the GTF trace 
is also formatted by ABDUMP for a SYSABEND 
data set even though ABEND9 does not speci- 
fy a trace in the SNAP request. 

The resources displayed for the subtasks 
and ancestors of the current task do not 
include the following items: PSW at entry 
to ABEND, register contents at entry to 
ABEND, the nucleus, load modules, and the 
subpool blocks. A subtask dump is identi- 
fied by the number 001, that of an ancestor 
by the number 002. 
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Figure 10-8. 



2, The job step consists of all 
the tasks shown in the 
figure. 

3. The figure shows a tree of 
tasks during a "task" 
termination, as opposed to 
a "step" termination. 
During a step termination 
the job step task is the top 
task of the tree, and all 
tasks of the job step belong 
to the tree. 



Task Relationships During an 
Abnormal Termination 



Cleanup after the Dumps ; After the dumps 
of the ancestors, ABEND9 performs several 
cleanup steps. It first dequeues the dump 
data set* resource so that is is available 
for use by the next requester of the ABEND 
routine. The parameters of the DEQ macro 
instruction are obtained from the extended 
save area of the ABEND routine's SVRB, 
where they were stored when the ENQ macro 
instruction was issued. Next, ABEND9 
deletes the resident module of ABDUMP 
(lEAQADOA) , so that its space, no longer 
needed for the current dumps, may be freed 
for other use. (Although the ABDUMP rou- 
tine has already issued a DELETE macro 



*The dump data set can be specified as SYS- 
ABEND or SYSUDUMP. 
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instruction for the same module, it is 
ineffective in releasing it, since the 
ABEND routine's request for the module is 
still outstanding.) When ABEND9 issues the 
DELETE macro instruction, the Delete rou- 
tine decreases the CDE use/responsibility 
count. If the count is now zero, the 
Delete routine releases the space occupied 
by the module, its load list element, CDE, 
and extent list. 

After dequeuing the dump data set 
resource and issuing a DELETE macro 
instiniction for ABDUMP's resident module, 
ABEND9 clears the ABDUMP and recursion 
flags in the current TCB. These had been 
set to indicate a valid recursion if an 
error had occurred during ABDUMP process- 
ing. Since this processing is finished, 
the bits are reset. This action completes 
the post-dump cleanup procedure, and ABEND9 
passes control to ABENDll. 

Processing during ABENDll (Entry Point 
IGCOBOIC) 

ABENDll performs the following 
functions : 

• Turn on the Generalized Trace Facility 
(GTF) for each task in the tree which 
had previously turned it off. 

• Purges ECBs awaited by programs asso- 
ciated with tasks in the terminating 
tree. 

• Erases complete subtasks. 

• Checks for storage to close and routes 
to steal. 

• Closes open data sets. 

• Frees the PIE. 

ABENDll calls the "task select" subrou- 
tine to select each task of the terminating 
tree, one task at a time. ABENDll then 
examines each task to see if a GTF trace 
suspension is still outstanding against the 
TCB. This is determined by examining the 
TCBGTOFM bit in the selected TCB. If set, 
a HOOK macro instruction is issued to 
resume the GTF trace. The TCBGTOFM bit is 
then reset, and the next task is selected. 

ABENDll next purges any ECBs that are 
awaited by programs associated with tasks 
in the terminating tree. The task select 
subroutine is called for each task; the 
"wait pending" flag (RBWAITP) in each RB 
associated with the selected task is then 
examined. If the RBWAITP flag is set 
(indicating that the RB is waiting on one 
or more ECBs), ABENDll locates the awaited 
ECBs by obtaining the contents of register 
1 at the time the WAIT macro instruction 



was issued. ABENDll marks the ECBs as com- 
pleted, and turns off the RBWAITP flag in 
the RB. This processing has the effqpt of 
causing any subsequent POST macro instruc- 
tion against the ECBs to be treated as a 
no-operation condition. 

ABENDll uses the Close routine of data 
management to close the data sets and purge 
the DEB queues. For a first^time entry 
ABENDll closes all data sets, and purges 
all DEBs. A recursive entry resumes Close 
processing from the point of the error. If 
a recursion has occurred from the Close 
routine (as indicated by the "Close recur- 
sion" flag TCBCLOSE in the current TCB) , 
ABENDll performs special processing to con- 
tinue closing data sets and purging DEBs. 
This processing is described under "Special 
Handling of a Recursion" below. 

CLOSING DATA SETS THAT BELONG TO THE TER- 
MINATING TASKS ; Data sets that are opened 
during task operation are normally closed 
(if they are not already closed) by the 
End-of-Task (EOT) routine. But since ter- 
minating tasks cannot reach the end-of-task 
condition, the ABEND routine must close all 
their data sets that are still open. 

The closing of data sets is performed 
separately for each task of the tree while 
the task is currently active. The "task 
select" subroutine selects the tasks, one 
at a time, starting with the newest descen- 
dant of the task specified for termination. 
The previously active task is set nondis- 
patchable, the newly selected task is made 
ready, the ABEND routine's SVRB is queued 
to the selected task's RB queue, a task 
switch is invoked, and a branch is made to 
the Dispatcher. When ABENDll is dispatched 
for the selected task it closes data sets, 
and purges DEBs. When all DEBs have been 
purged, the "task select" subroutine 
selects the next higher level task in the 
tree, and the process is repeated. 

Selecting Each Task of the Tree ; On each 
iteration of the loop in which data sets 
are closed, the "task select" subroutine 
selects another task of the terminating 
tree. Its first selection is the newest 
descendant of the task specified for ter- 
mination. For example, in Figure 10-8 the 
newest descendant is task G, and the task 
specified for termination is task D. On 
each iteration, the next higher level task 
is selected. The next higher level task is 
F. On the final iteration of the loop, the 
highest level or "top" task of the tree is 
selected. The top task of the tree is D. 
The direction of selettion is thus from 
bottom to top of the tree. 

For each selection, the "task select" 
subroutine tests the "completion" flag 
(TCBFC) to learn whether the task has 
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already been terminated (either normally or 
abnormally) .If the selected task has 
already been terminated, and its TCB is 
thus no longer needed, ABENDll branches to 
the resident "erase" routine (part of the 
EOT routine) with the address of the ter- 
minated TCB. The "erase" routine dequeues 
the selected TCB from the subtask queues 
(whose pointers are TCBLTC and TCBNTC in 
each TCB) and frees the space it occupies. 
When control returns from the "erase" rou- 
tine, the "task select" subroutine makes 
another selection and again checks the 
"completion" flag. When an incomplete or 
not-already terminated task has been 
selected, the next part of ABENDll is pre- 
pared for dispatching under control of the 
selected TCB. 

Preparation for the Dispatching of ABENDll 
Under Control of the Selected Task ; As 
stated before, closing data sets is done 
\mder the control of the task to which 
these resources belong. For this purpose, 
the ABEND routine's SVRb must be queued to 
the selected task's RB queue. The selected 
task must then become the active task, 
replacing that which was previously cur- 
rent. Under control of the newly selected 
TCB, ABENDll is redispatched (at location 
ENTRY2) to begin execution of its "close 
data sets" function. 

Preparation for the redispatching of 
ABENDll occurs as follows. First, the cur- 
rent task is set nondispatchable (TCBABWF 
flag is set) so that ABENDll temporarily 
cannot be redispatched for this task. The 
task selected by the "task select" subrou- 
tine is then made dispatchable (two bytes 
of non-dispatchability flags are cleared in 



its TCB) in preparation for the branch to 
the Dispatcher. ABENDll stores in the RB 
old PSW field (RBOPSW) of ABEND'S SVRB the 
entry point (ENTRY2) to its "close data 
sets" function, for later use by the Dis- 
patcher. Then, to permit ABENDll to con- 
trol processing for the selected task, the 
ABEND routine's SVRB is placed at the head 
of the selected task's RB queue. The 
TCBRBP field of the selected TCB is altered 
to point to the ABEND routine's SVRB, and 
the ABEND routine's SVRB points to the pre- 
viously "top" RB of the queue. (Refer to 
Figure 10-9.) The ABEND routine's SVRB is 
then removed from the RB queue of the pre- 
viously current TCB, since ABENDll can ser- 
vice only one task at a time. 

To ensure that the registers contain the 
correct values when ABENDll is redispatched 
for the selected task, the address of the 
selected TCB is placed in the TCB register 
(register H) , and the current general 
register contents are stored in the regist- 
er save area (TCBGRS) of the selected TCB. 
The Dispatcher, when invoked, loads the 
registers from this TCB save area. 

ABENDll next branches to the Task Switch 
routine, making available the address of 
the selected TCB. The Task Switch routine 
compares the dispatching priority of the 
input TCB with the dispatching priority of 
the last dispatched (previously current) 
TCB. If the selected task is of higher 
priority, the Task Switch routine places 
the selected TCB address in the "new" TCB 
pointer (lEATCBP) as an indication to the 
Dispatcher. Otherwise, the Dispatcher 
would try to select either the previously 
current task (now nondispatchable) , or 



- pointer 




Note: abend's SVRB is shifted to tlie RB queue of the currently selected task. 

Figure 10-9. Preparation for the Dispatching of ABENDll for the Selected Task 
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another lower priority task by a search of 
the TCB queue in a downward- priority 
direction . 

Finally, ABENDll branches to the Dis- 
patcher which passes control to ABEND'S 
"close data sets" function for the selected 
task. When this task has highest priority 
among the ready tasks (perhaps after a 
delay in which other tasks are active) , 
ABENDll is redispatched (at location 
ENTRY2) to purge data sets for the selected 
task. 

Closing Data Sets for a Selected Task ; The 
closing of data sets for a selected task 
consists of issuing a CLOSE macro instruc- 
tion (with resulting supervisor linkage to 
the close routine of data management) for 
each data set opened for the task. Each 
data set is specified by a DCB; the address 
of the DCB is contained in a DEB whose 
queue belongs to the task. After a data 
set is closed, its associated DEB is 
removed from the task's DEB queue, and its 
space is freed. If a recursion to the 
ABEND routine occurs because of a defective 
DCB, or an incorrect DEB address in a DCB, 
the DEB is dequeued and freed, although its 
data set is not closed. After each DEB has 
been freed, ABENDll frees the program 
interruption element (PIE), which may have 
been created by a SPIE macro instruction in 
a user tape label routine. 

Prior to closing data sets, ABENDll 
issues a GETMAIN instruction to test wheth- 
er there is sufficient storage for the 
Close routine. If the GETMAIN should fail, 
an XCTL is issued to link to ABEND12, which 
attempts to free ("steal") the necessary 
storage. Once storage has been obtained, 
ABENDll closes data sets and purges DEBs. 

If the pointer to the task's DEB queue 
(TCBDEB) is not zero, there are data sets 
belonging to the task that must be closed. 
Before issuing CLOSE macro instructions, 
ABENDll stores the flag byte, and the DCB 
address that was obtained from the first 
DEB, in the parameter list for the close 
routine. The parameter list is the second 
word of the extended save area of the ABEND 
routine's SVRB. (See SVRB format in Sec- 
tion 12, "Control Blocks and Tables.") The 
high-order bit of the parameter list is set 
to indicate to the Close routine that the 
specified data set is the last in a list of 
data sets. (See Data Management Macro 
Instructions . ) 

After setting up parameters for the 
Close routine, ABENDll saves the current 
DEB address in the extended save area of 
the ABEND routine's SVRB. The purpose is 
to check whether the Close routine is able 
to perform its secondary functions: updat- 
ing the DEB pointer (TCBDEB) , and freeing 



the current DEB. After regaining control 
from the Close routine, ABENDll compares 
the DEB pointer with the saved DEB address 
to determine if the Close routine has both 
removed the current DEB from the DEB queue 
and freed its space. 

Next, before invoking the Close routine, 
ABENDll sets the "close" and "recursion" 
flags (TCBCLOSE and TCBREC) in the selected 
TCB. If an error occurs during the Close 
routine (possibly caused by an invalid 
DCB) , the set condition of these flags 
indicates a valid recursion to the ABEND 
routine, and causes reentry to ABENDll from 
ABEND3 to continue the DEB processing. 

ABENDll invokes the Close routine data 
management by issuing a CLOSE macro 
instruction specifying the parameters it 
had previously stored in its SVRB. The 
resultant SVC interruption causes the SVC 
Second-Level Interruption Handler to create 
an SVRB for the Close routine and to place 
the SVRB on the RB queue of the selected 
task. When the Close routine finishes its 
processing, the resultant SVC interruption 
causes supervisor linkage to the Exit rou- 
tine, which removes the Close routine's 
SVRB from the RB queue, and frees its 
space. The ABEND routine's SVRB is then 
left as the current RB for the task. 

After the execution of the Close rou- 
tine, the Dispatcher returns control to 
ABENDll as the current routine for the 
still-active current task. ABENDll resets 
the "close" and "recursion" flags in the 
selected TCB to indicate that a recursion 
(if it now occurs) is not valid. These 
flags are set again just before the 
issuance of the CLOSE macro instruction for 
the next data set. 

The TCBDEB pointer is compared with the 
saved DEB address to determine if the cur- 
rent DEB was dequeued and freed by the 
Close routine. If the two DEB addresses 
are unequal, the current DEB has been 
freed. ABENDll then branches to free the 
PIE. 

If the two DEB addresses are equal, the 
Close routine did not process the current 
DEB. Accordingly, ABENDll provides a 
pseudo-link (via an SVC 13) to the GAM 
module IGGIFFOl. This link results in a 
reentry into ABENDO, which issues an XCTL 
to link to IGGIFFOl, thus giving the GAM 
module its own SVRB. ABEND uses a reentry 
configuration across the pseudo-link, and a 
valid recursion configuration (TCBCLOSE) 
across GAM processing. The valid recvirsion 
configuration across GAM processing is 
necessary should IGGIFFOl itself abnormally 
terminate such as for an invalid DEB or UCB 
data. (Note that ABEND does not ensure the 
validity of the DEB vrtiich GAM is process- 
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ing. The DEB is the one addressed by the 
current TCBDEB field.) If IGGIFFOl ter- 
minates abnormally, control passes through 
ABEND to the module that invoked the GAM 
routine; processing continues as if the 
interface had been normal. 



After GAM has completed processing, it 
issues an SVC 3 (EXIT) which causes its 
SVRB to be dequeued, and control returned 
to ABENDll. ABENDll first resets the 
recursion configuration flag. It then 
dequeues the DEB from the DEB queue, deter- 
mines its size, and frees the space it 
occupies. If the TCB points to a PIE, the 
pointer is cleared and the PIE is freed. 
After the PIE has been freed, ABENDll 
branches to repeat the processing for the 
next DEB. The GAM module IGGIFFOl is 
entered for each DEB that has not been 
dequeued by the Close routine. 



Special Handling of a Recursion ; An error 
can occur during the execution of the Close 
routine, causing a recursion to ABEND. 
Such an error can be caused by overlaying 
one or more DCBs because of the "steal 
core" function of ABEND12. Regardless of 
the cause, a recursion because of an error 
during the close routine needs special han- 
dling to permit continued closing of data 
sets after the point of error. 

If a recursion to the ABEND routine 
occurs because of an error during the Close 
routine, ABENDS invokes ABENDll directly to 
continue closing data sets and purging 
DEBS. A test at the beginning of ABENDll 
recognizes the set condition of the "close" 
indicater in the selected TCB, and branches 
to perform special handling. 

ABENDll first locates the DEB on which 
the Close routine was operating when the 
error occurred. It locates the DEB address 
by searching the RB queue to find the SVRB 
that was used during the previous execution 
of the ABEND routine. This SVRB holds the 
last used DEB address in its extended save 
area. The DEB address was placed in the 
extended save area by ABENDll during its 
previous execution, just before it issued 
the last CLOSE macro instruction. The last 
used DEB address, when found, is saved in 
the extended save area of the SVRB used for 
the current execution of the ABEND routine. 

ABENDll continues processing as if con- 
trol had just been returned from the Close 
routine after normal DEB processing. The 
"close" and "recursion" flags are cleared, 
and the current DEB (since it was not freed 
by the Close routine) is dequeued from the 
DEB queue and freed. Normal DEB processing 
for the next DEB then continues, as pre- 
viously described. 



When all DEBs have been closed, ABENDll 
determines where to transfer control. If 
the current task is the top task in a tree 
which is abnormally terminating, ABEND13 
receives control. Otherwise, a subtask is 
selected for termination via redispatching 
to this ABEND module. 

Processing during ABEND12 (Entry Point 
IGCOCOIC) 

ABEND12 has two main purposes: 

• Determines whether the storage required 
by the Close routine is available. 

• Attemptes to obtain storage if the 
ABEND is a job- step ABEND. 

ABEND12 tests whether storage is avail- 
able for use by the Close routine during 
ABENDll processing. If sufficient storage 
is available (552 bytes) , control is passed 
back to ABENDll to continue the termination 
procedures . 

If the required storage area cannot be 
obtained, ABEND12 follows either of two 
paths, depending on viiether the current 
termination is for the entire job step or 
only for the specified task and its descen- 
dants. If the current termination is for 
the job step, ABEND12 "steals" (frees) pre- 
viously allocated main storage for the 
Close routine, preferably from space allo- 
cated to the job-step task. This space is 
in subpool 252. 

If the current termination is not for 
the job-step task, the task termination 
must be converted to a job-step termina- 
tion. This is because the "stealing" of 
allocated main storage has made impossible 
the normal continuation of the job step. 
ABEND12 prepares for a job-step termina- 
tion. It does this by putting the comple- 
tion code in the ESA, and setting the conv- 
ersion configuration flag (TCBCONVR) . It 
then passes control to ABENDl which extends 
the ABEND to include the entire job step. 
When the "check for core" subroutine in 
ABENDll is entered for the second time, the 
test for available main storage, and the 
"stealing" of needed storage (if necessary) 
occur just as they would for an original 
job-step termination. 

DETERMINING WHETHER STORAGE IS AVAILABLE ; 
The "steal core" subroutine, used by 
ABEND12, tests for the availability of main 
storage for the Close routine. It issues a 
conditional GETMAIN macro instruction for 
552 bytes of main storage. The availabili- 
ty or unavailability of this amount of 
storage is indicated by the code returned 
by the GETMAIN routine in the return code 
register. If the space is available, it is 
immediately freed, since the purpose of the 
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GETMAIN macro instruction is merely to test 
availability. In this case, ABEND12 passes 
control back to ABENDll. 

ATTEMPTING TO "STEAL CORE" ; If main 
storage is not available, the "steal core" 
subroutine tests if the current termination 
is for the entire job step. If it is not, 
conversion to step termination and purging 
resources for the enlarged tree of tasks 
occurs as previously described. But if the 
termination is for the entire job step, the 
subroutine tries to obtain main storage for 
the Close routine of ABENDll by attempting 
to "steal" allocated storage from one of 
the tasks of the job step. 

The "steal core" subroutine next sets 
the "prevent dump" indicator (TCBPDUMP) in 
the job-step TCB. This flag is set only to 
indicate that storage has been stolen. 

The "steal core" subroutine tries to 
find previously allocated subpool 252 space 
belonging to the job-step task. It tries 
to locate this space in preference to other 
subpools, since subpool 252 within a region 
ordinarily does not hold data control 
blocks (DCBs) . Thus, the "stealing" of 
allocated space from this subpool will pro- 
bably not cause recursions to the ABEND 
routine when ABENDll refers to the DCBs to 
close data sets. The subroutine searches 
the subpool queue of the job-step TCB, 
looking for a subpool queue element (SPQE) 
for subpool 252. If it finds such an SPQE 
before it exhausts the SPQE queue, it 
issues a FREEMAIN macro instruction to free 
the entire subpool, and tests for the avai- 
lability of main storage. It makes this 
test by issuing a macro instruction condi- 
tional GETMAIN for 552 bytes, followed by a 
FREEMAIN macro instruction. If storage is 
now available (as indicated by the condi- 
tion code returned by the GETMAIN routine) , 
the work of the subroutine is finished. 

If the "steal core" subroutine cannot 
find an area assigned to subpool 252 that 
belongs to the job-step task, it then looks 
for any allocated subpool that belongs to 
any task of the job step. By use of the 
"task select" subroutine and the MSSLOOP 
subroutine, the main storage queues of each 
task in the job step are searched for a 
descriptor queue element (DQE) . If a DQE 
exists, main storage is already allocated 
to the associated subpool. The "steal 
core" subroutine places zero in the "free- 
queue element" pointer in the DQE. It does 
this to simulate an absence of free storage 
in the blocks described by the DQE. The 
purpose is to prevent the error of trying 
to free an area that is already free. To 
make storage available for the Close rou- 
tine, the subroutine frees (via a branch to 
the FREEMAIN SVC routine) a block of 2K 
bytes of the area described by the DQE. If 



the SPQE is for subpool 0, the FREEMAIN 
parameters must specify subpool 250. 

EXITING FROM ABEND12 ; ABEND12 passes con- 
trol, via an XCTL, to ABENDl if conversion 
to a job step ABEND is necessary. ABENDll 
receives control if storage is available 
for the closing of data sets. In the 
situation in which the "steal core" subrou- 
tine fails to obtain storage, control 
passes to DARl because this is an invalid 
system condition. 

Processing during ABEND13 (Entry Point 
IGCODOIC) 



ABEND13 performs the following: 

• Passes control to the TCAM close 
module. 

• Frees SCBs. 

• Cancels Inter-Partition Posts for TCAM 
and TSO tasks. 

• Purges QELs. 

• Purges transient SVRBs. 

• Purges dynamic DD entries (in the TIOT) 
invalidly marked busy. 

ABEND13 first checks whether entry to 
this module is a recursion or a first-time 
entry. If the recursion is due to an error 
in the purge routines of TSO or TCAM Inter- 
Partition Posts, the respective routines 
are not reentered. If the recursion is due 
to an error in the TIOT Check routine, pro- 
cessing continues with the removal of tran- 
sient SVRBs. For a first-time time entry, 
the "task select" subroutine is called to 
select a task to be purged. If one is 
found, normal processing takes place. If a 
task is not selected to be purged, ABEND13 
performs its exit processing. 

TCAM CLOSE MODULE INTERFACE ; ABEND13 gives 
control to the TCAM Close module which per- 
forms closing functions for TCAM if they 
have been bypassed in normal close process- 
ing or close recursion. The interface of 
ABENDl 3 with the TCAM Close module is via a 
pseudo SVC with a recursion configuration 
set across TCAM Close processing. 

CANCELLATION OF PENDING INTER- PARTITION 
POSTS FOR TCAM ; In a TCAM environment, 
there may be a pending request to post this 
task by another task. SVC 102 is an SVC 
instruction which effectively cancels such 
pending requests. If those requests ere 
not canceled, this task could terminate and 
another task, possibly having the same 
TJID, TCB address, and RB address, could be 
posted by mistake. 
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FREEING OF STAE CONTROL BLOCKS: 



If an SCB 



exists, as indicated by an address in the 
TCBNSTAP field, the SCB chain is updated 
and a FREEMAIN instruction is issued to 
free each SCB. 

CANCELLATION OF PENDING INTER- PARTITION 
POSTS FOR TSO ; In a TSO environment, there 
may be a pending request to post this task 
by another task, possibly swapped out at 
this time. QTIP is a macro which will 
effectively cancel all such pending 
requests. If those requests were not can- 
celed, this task could terminate and anoth- 
er task, possibly having the same TJID, TCB 
address, and RB address as this task, could 
be posted by mistake. 

If TSO is active, this macro must be 
called even if this is not a TSO task. 
This task could be a foreground initiated 
background task, and thus pending requests 
must be canceled. 

This macro call is made for each task in 
the tree of terminating tasks. Because 
QTIP may be called more than once for a 
terminating task without complications, no 
special precautions are necessary to avoid 
a second call during recursive processing. 
However, if entry to ABEND13 is due to a 
QTIP recursion, QTIP processing is 
bypassed. 

ENQ/DEQ PURGE ; If the selected task is not 
the top task in the tree, ABEND13 enters 
the resident ENQ/DEQ Purge routine (at 
entry point lEAOEQOl) to remove resource 
requests generated by issuing the ENQ macro 
instruction for the selected task. This is 
the task selected by the "task select" sub- 
routine from those belonging to the ter- 
minating tree. The queue elements (QELs) , 
representing resource requests, must be 
removed. This is done so that routines 
belonging to other tasks can gain access to 
the enqueued resource, if the abnormal ter- 
mination occurred before the DEQ routine 
could be executed for the selected task. 
Otherwise, the resource would remain 
inaccessible. 

The ENQ/DEQ Purge routine searches the 
system QCB chain for QELs that were con- 
structed by the ENQ routine for the 
selected task. Each QEL contains a pointer 
to the TCB under whose control it was con- 
structed. Each QEL belonging to the 
selected task is removed from its QEL 
queue, and its space is freed, via a branch 
to the FREEMAIN routine. If all QELs 
queued to a minor QCB are removed, the 
minor QCB is also dequeued from its major 
QCB and its space is freed. If the major 
QCB has no minor QCB, it is also removed 
from its queue and its space is freed, 
when all the task's enqueued requests have 
been removed from the system QCB chain and 



its related queues, the ENQ/DEQ Purge rou- 
tine returns to ABEND13 which must reestab- 
lish addressability. 

The ABEND13 routine must also terminate 
device reservations acquired through the 
RESERVE macro instruction and not released 
through a subsequent DEQ macro instruction. 
These device reservations occur only in 
systems with the shared DASD option . 

Outstanding reservations are reflected 
in the TCB enqueue count. When such a 
reservation is detected, the ENQ/DEQ Purge 
routine branches to the EXCP interface sub- 
routine in the ENQ/DEQ module. This sub- 
routine prepares control blocks for an EXCP 
command and issues the EXCP command that 
results in the release of the reserved 
device. For this reason it is essential 
that the ENQ/DEQ Purge be done in an ABEND 
module which runs partially enabled. 

When all QELs and QCBs for the selected 
task have been purged, the "task select" 
(TASKSEL) routine is invoked to select the 
next higher level task of the tree. 

REMOVAL OF REQUEST BLOCKS -FOR TRANSIENT SVC 
ROUTINES: ABEND13 locates SVRBs for tran- 
sient routines by searching the RB queue 
belonging to the selected task. (Each next 
RB is pointed to by the RBLINK field of the 
previous RB, beginning with the ABEND rou- 
tine's SVRB. ) Each RB is examined to 
determine that it is an SVRb and that it 
represents a transient routine, as indi- 
cated by the bit settings in the RBSTAB 
field. Each SVRB for a transient routine 
is removed from the task's RB queue. Then 
ABEND13 branches to subroutine TAHABEND to 
remove the SVRB from the transient area 
queues . 

The TAHABEND subroutine first tests the 
transient area block number (RBTABNO field) 
of the SVRB to determine if the represented 
routine is currently in a transient area 
block (TAB). If this field is zero, the 
SVC routine is not in a TAB. In this case, 
the subroutine searches the transient area 
request (deferred) queue for a pointer to 
the SVRB. If the SVRB address is found, it 
is removed from the request queue and the 
purge of the transient area is complete. 

If, however, the TAB number (RBTABNO) in 
the specified SVRB is not zero, the SVRB 
address is on a user queue and the asso- 
ciated routine is either in a TAB or was 
overlaid before it could be completed. In 
this case, the transient area user count is 
decreased by one to indicate one less out- 
standing request for the routine in the 
TAB. Then, by use of the TAB number as a 
displacement, the associated entry in the 
transient area control table (TACT) is 
found. By means of the TACT entry, the 
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appropriate user queue is located and 
searched for the SVRB address. When the 
specified SVRB address is found, it is 
dequeued from the user queue, since the 
requester that originally generated the 
SVRB is being terminated. The user queue 
for the TAB is then searched to determine 
if there are other users of the routine in 
the TAB. (The relative track and record 
address — TTR — in the TACT entry, represent- 
ing the routine now in the TAB, is compared 
with the TTR in the remaining SVRBs on the 
user queue.) If the search indicates that 
there are other users of the routine, the 
purge of the transient area queues is com- 
plete. But if it indicates that there are 
no other users of the routine in the TAB, 
the associated TACT entry is flagged to in- 
dicate a free TAB. 

When control returns from the TAHABEND 
subroutine, ABEND13 determines the size of 
the SVRB just processed (from its rbsiZE 
field) and frees the space it occupies, 
specifying subpool 255 (one of the subpools 
of supervisor queue space) . 

TIOT CLEANOP ; After processing has been 
completed for each task in the terminating 
tree, a check is made to determine if the 
terminating task is a time-sharing subtask 
that did not reenter ABEND13 because of a 
TIOT recursion (TCBDYNAM) . If this is the 
case, the TIOT Check module is entered to 
perform cleanup processing for dynamic DD 
entries in the TIOT. 



EXIT PROCESSING ; 
ABEND15. 



ABEND13 passes control to 



Processing during ABEND15 (Entry Point 
IGCOFOIC) 

ABEND15 purges CDEs, associated pro- 
grams, and extent lists. 

ABEND15 selects each task by means of 
the previously described "task select" sub- 
routine, starting with the newest descen- 
dant of the specified task and ending with 
the specified or "top" task itself. But 
unlike the processing of ABENDll, in which 
each task was redispatched under the con- 
trol of abend's SVRB to purge its own 
resources, all of ABEND15"s processing is 
done under the control of one task, the 
specified or top task of the terminating 
tree. This task remains dispatchable 
throughout the execution of ABEND for the 
current request. 

Purging the Contents Directory for a PRB ; 
A check is made of the RB chain of the 
selected TCB. If the RB examined is a PRB, 
there is an associated contents directory 
entry (CDE) which must be examined, and if 
necessary, purged from the contents direc- 
tory. To examine the CDE, which represents 



a load module, a branch is made to the sub- 
routine CDTERM to test the CDE and possibly 
update the associated queues. 

If the CDE pointer (RBCDE) in the PRB is 
zero, there is no CDE associated with the 
PRB. There is, therefore, no need for 
CDTERM to update the contents directory. 
The search of the RB chain continues. 

If the CDE pointer (RBCDE) in the PRB is 
not zero, there is a CDE, which means that 
a load module is associated with the PRB. 
The load module may be in the process of 
being loaded, or may already be residing in 
main storage. The status of the module may 
be determined by a test of the CDE's CDATTR 
flags. For the format and contents of a 
CDE, see Section 12, "Control Blocks and 
Tables." 

If the module described by the CDE is in 
the process of being loaded (as indicated 
by the "set" condition of its NIC flag) the 
FREEFWA subroutine frees the fetch work 
area, obtains the major CDE if the current- 
ly examined CDE is a minor (since altera- 
tions are always made in the major CDE) , 
and processes according to two possible 
situations: 

1. The module is being loaded under con- 
trol of another PRB, not the selected 
PRB. A test of the CDERB field shows 
that it does not point to the selected 
PRB. The selected PRB is on a queue*- 
of PRBs waiting for the module to be 
loaded for another task in the job 
step. In this case, the removal of 
the selected PRB from the waiting 
queue has no effect on other tasks 
whose PRBs are waiting. Accordingly, 
CDTERM branches to its DQRBS subrou- 
tine to remove the selected PRB from 
the queue of waiting PRBs. CDTERM 
then returns control to the RBREMOVE 
subroutine to remove the selected PRB 
from its task's RB queue and free its 
storage area. 

2. The module is being loaded under con- 
trol of the selected PRB. (The test 
of the CDERB field shows that it 
points to the selected PRB.) In this 
case, the processing depends on wheth- 
er there are other PRBs queued*- to the 
selected PRB. 

Purging the Module and Related Storage 
Areas ; If a test of the RBPGMQ field indi- 
cates that no other PRBs in the job step 
are waiting for the module to be loaded, 
the CDE and its related areas can be 
removed without adversely affecting other 
tasks. Accordingly, ABEND15 branches to 
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the FREEMAIN routine to free the module's 
storage area (conditionally) and its asso- 
ciated extent list (if it exists) . It then 
dequeues the major CDE for the module and 
any minor CDEs and, via the FREEMAIN rou- 
tine, frees the space they occupy. 

Preparation for Ref etching the Module ; If 
PRBs for other tasks of the job step are 
queued, waiting for the module to be 
loaded, the loading process cannot be 
stopped without ensuring that the module is 
loaded under control of one of the waiting 
PRBs. Otherwise, the tasks whose PRBs are 
waiting would be permanently nondispatch- 
able, waiting for a resource that is never 
available. Accordingly, ABEND15 prepares 
for the refetching of the module by the 
routines of Contents Supervision. It then 
frees the program area and extent list, if 
they exist, and dequeues and frees the 
major CDE and any minors. 

Preparation for the refetching of the 
module consists of making the waiting PRBs 
ready to enter the CDSEARCH routine of Con- 
tents Supervision at entry point CDCONTRL. 
This routine initializes the request for 
the module. Other routines of Contents 
Supervision perform the fetch and update 
the contents directory. ABEND15 prepares 
the waiting PRBs for entry to location 
CDCONTRL by performing the following steps 
for each queued PRB, using the subroutine 
QDRBS: 

1. Frees the fetch work area, if one has 
been allocated. (This action has 
already been done for the selected 
PRB.) 

2. Stores the address CDCONTRL in the old 
PSW field of the PRB, in preparation 
for the dispatching of the CDSEARCH 
routine, mentioned above. 

3. Reinitializes the RB by: placing zero 
in its wait count field (RBWCF) , thus 
removing it from the wait condition; 
placing zero in the CDE pointer 
(RBCDE) , since Contents Supervision 
stores a new CDE pointer in this 
field; and placing zero in the queuing 
field (RBPGMQ) , since the RB is no 
longer in the waiting queue. Contents 
Supervision creates a new waiting 
queue of requesting SVRBs during the 
reinitialized fetch process. 

H. Decreases by a count of one the use/ 
responsibility count in the major CDE, 
in order to indicate that there is one 
less outstanding request for the 
module. 

5. Locates the address of the TCB asso- 
ciated with the waiting PRB by chain- 
ing through the RB queue, following 



the RBLINK fields, and branches to the 
supervisor's Task Switching routine 
with this TCB address. The Task 
Switching routine may alter the "new" 
TCB pointer (lEATCBP) to permit the 
Dispatcher to eventiially pass control 
to location CDCONTRL for a task which 
is of higher priority than the current 
task. 

The reinitialized request for the module 
causes execution as soon as one of the 
tasks whose RBs have been readied is next 
dispatched. 

After ABEND15 has reinitialized the 
module request, it frees the program area 
and extent lists, if they have been 
acquired. It dequeues and frees the major 
CDE and any minors from the Job Pack Area 
Queue (JPAQ) . When contents Supervision is 
eventually dispatched, it does not find a 
CDE for the module, since the CDE has been 
removed from the contents directory. Con- 
tents Supervision, therefore, begins the 
process of fetching the module. 

Processing if the Module Is Already in Main 
Storage ; If the module described by the 
CDE is already in main storage, ABEND15 
performs processing roughly parallel to 
that which it performs if the module is in 
the process of being loaded. There are, 
however, several differences: 

• No fetch work areas are freed, since 
Contents Supervision has already freed 
these areas. 

• Preparation for the refetching of the 
module occurs only if the module is 
serially reusable. The reasoning is 
that the module may now not be reus- 
able, either because of a program check 
during its execution or because it 
could not finish and therefore could 
not reinitialize itself. In either 
case, waiting queued PRBs are made 
ready and pointed to location CDCONTRL, 
as previously described. But to force 
ref etch by Contents Supervision, 
ABEND15 clears the "serially reusable" 
flag and sets the "nonreusable" flag in 
the CDE. If the module was not reus- 
able, this flag was already set. 

• Instead of freeing the program area, 
extent list, and the CDE unconditional- 
ly if the selected PRB is in control of 
the module, ABEND15 branches to entry 
point HKPPROC, a subroutine of the Exit 
routine, to test the CDE use/ 
responsibility count. If this count is 
zero, indicating that there are no out- 
standing requests for the module, 
ABEND15 branches to the CDHKEEP subrou- 
tine and to two other subroutines of 
the Exit routine (CEDESTRY and 
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ORDERCDQ) to free the program area, 
extent list, and the CDE. (For further 
information about CDHKEEP, CDDESTRY, 
and ORDERCDQ, see Section 9 "Exiting 
Procedures.") 

If contents directory processing by the 
CDHKEEP subroutine is not needed because 
the selected PRB is not in control of the 
module, the selected PRB is removed from 
the RB "wait" queue*- that originates in the 
CDE. The use/responsibility count is then 
decreased by a count of one to indicate 
that there is one less outstanding request 
for the module. 

The result of the processing by ABEND15 
is that the selected PRB has been removed 
from the CDE's RB queue of waiting request- 
ers, or the request for the module has been 
reinitialized and, if necessary, the pro- 
gram area, extent list, and CDE have been 
freed. 

EXITING FROM ABE1SID15 ; After ABEND15 has 
completed processing all PRBs for all tasks 
of the terminating tree, it exits to 
ABEND16 to continue task purges. 

Processing during ABEND16 
(Entry Point IGCOGOIC) 

ABEND16 performs the following 
functions ; 

• Purges IRBs, PRBs, and resident SVRBs. 

• Purges the load list. 

• Purges dynamically acquired main 
storage. 

• Releases the task control block. 

• Provides final processing for the top 
task of the tree. 

ABEND16 purges the remaining resources 
of the specified task and its descendants. 
These resources include: IRBs, PRBs, and 
resident SVRBs; the load lists; and dynam- 
ically acquired main storage if exclusively 
owned. ABEND16 selects the tasks whose 
resources are to be purged in a manner 
similar to that of ABEND15. 

After ABEND16 has purged all resources 
belonging to a selected task, it removes 
the task's TCB from the TCB queue and from 
the subtask queues, and frees the main 
storage that the TCB occupies. 

As a last function, ABEND16 loads the 
return register with the completion code 
obtained from the top TCB. This completion 
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code is then available to the top task's 
parent, the next higher level task, for its 
examination. 

ABEND16 twice causes supervisor linkage 
to the Exit routine. The Exit routine dur- 
ing its first execution updates the tran- 
sient area control table and the transient 
area queues, via its TAXEXIT subroutine. 
It does this because ABEND16, a transient 
SVC routine, is finished. During its first 
execution the Exit routine also removes the 
ABEND routine's SVRB from the top task's RB 
queue and frees its storage space. During 
its second execution the Exit routine, 
detecting an end-of-task condition, 
branches to the EOT routine. 

The EOT routine performs final termina- 
tion procedures for the top task of the 
tree. These procedures consist of: 

• Passing control to an end-of-task exit 
routine (ETXR), if one has been 
specified. 

• Posting an event control block (ECB) 
for the parent task, if an ECB has been 
specified. 

• Removing the top TCB from its queues 
and freeing its storage space. 

When control returns from the EOT rou- 
tine, the Exit routine removes the last RB 
from the top task' s RB queue and frees its 
storage space. The Exit routine then 
branches to the Transient Area Refresh rou- 
tine to refresh (if necessary) a transient 
area. The transient area may have been 
overlaid by the modules of the ABEND 
routine . 

The Transient Area Refresh routine, when 
its processing is complete, branches to the 
Dispatcher. The Dispatcher then gives con- 
trol to the current routine of the highest 
priority ready task. 

ABEND16 purges resources for and removes 
the TCB of each lower task in the tree 
structure beginning with the lowest task 
and moving upward. The process continues 
until the top task of the tree has been 
selected and its resources purged. This 
time the TCB is not removed from its 
queues, nor is its space freed, since this 
TCB is still needed after ABEND16 exits. 

PURGING REQUEST BLOCKS ; The resources 
first purged by ABEND16 for a selected task 
are the request blocks (RBs) . The RBs are 
processed by a subroutine called RBREMOVE. 
The processing varies according to the type 
of RB: SVRBs for resident routines, IRBs, 
and PRBs. The type of RB is determined by 
a test of the RBFTP bits of the RBSTAB 
field. For the format and contents of each 
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type of RB, see Section 12, "Control Blocks 
and Tables." 

Purging an IRB ; If the RBREMOVE subroutine 
finds an IRB that represents a user or sys- 
tem exit routine, it dequeues all IQEs or 
RQEs that are queued to it. The subroutine 
then decreases the "use count" in the IRB, 
according to the number of IQEs or RQEs 
that it removed. (The use count, stored in 
the IRB when the user exit routine was 
first requested, indicates multiple use of 
the same exit routine for different 
subtasks. ) 

The RBREMOVE subroutine removes the IRB 
from the task's RB queue, and resets the 
"active" flag (RBFACTV) in the IRB to indi- 
cate to the Stage 3 Exit Effector that the 
IRB is not on a task's RB queue. 

Then two tests are made to determine if 
space belonging to the IRB may be freed. 
If the IRB's storage space was not dynamic- 
ally acquired (as indicated by a test of 
the RBFDYN flag in the RBSTAB field), the 
RB is a permanent system interruption re- 
quest block and may not be freed. Or if 
the IRB'S use count is greater than zero, 
it is still needed, and should not be 
freed. In either case, the RBREMOVE sub- 
routine processes the next RB on the 
selected task's RB queue, or if there is no 
other RB on the queue, passes control to 
ABEND16's Load List Purge routine. But if 
the IRB is not a system RB and contains a 
use count of zero, it is no longer needed 
and its space is freed. If it has a user 
register save area, originally reserved by 
the requestor of the user exit routine, the 
save area space is freed. (Existence of 
the save area is indicated by a nonzero 
RBPPSAV field in the IRB.) The 72-byte 
save area is conditionally freed from sub- 
pool 250 by a branch to the FREEMAIN rou- 
tine (address FMBRANCH) . If the IRB is a 
TAXE, (in a system with TSO) , the TAIE 
(terminal attention interruption element) 
is similarly freed. The RBREMOVE subrou- 
tine then branches to the FREEMAIN routine 
to free the IRB's space from subpool 253. 
If there is another RB on the selected 
task's RB queue, the subroutine processes 
it. Otherwise, it passes control to 
ABEND16's Load List Purge routine. 

Removing the PRB ; If the RB is found to be 
a PRB, the RBREMOVE subroutine removes the 
PRB from its task's RB queue and frees its 
storage area. The freeing of the PRB's 
storage area is similar to that for any 
other RB's storage area except that there 
is no user register save area to be freed, 
and the RB size and subpool number pertain 
to a PRB. The RBREMOVE subroutine branches 
to the FREEMAIN routine at entry point 
FMBRANCH to free the PRB's storage space 
from subpool 255. Then, if there is anoth- 



er RB on the selected task's RB queue, the 
RBREMOVE subroutine purges that RB in the 
manner previously described. But if there 
are no more RB's belonging to the selected 
task, the RBREMOVE subroutine passes con- 
trol to the Load List Purge. 

Purging an SVRB ; Since SVRBs for transient 
routines have already been released by 
ABEND13 any SVRB detected by the RBREMOVE 
subroutine must represent a resident SVC 
routine. If the SVRB is not the last RB of 
the "top" TCB, the RBREMOVE subroutine 
removes the SVRB from the task's RB queue, 
determines its size from its RBSIZE field, 
sets up the subpool operand (255) for a 
branch entry to FREEMAIN, and frees the 
space occupied by the SVRB. If the SVRB is 
not the last RB on the selected task's RB 
queue, the next RB is obtained and RB pro- 
cessing for the task continues. 

If the SVRB is the last RB on the top 
task's RB queue, the RBREMOVE subroutine 
does not release the SVRB. This last SVRB, 
used for the ABEND routine, is released by 
the Exit routine after ABEND16 is finished. 

Special Processing for the Last RB of the 
"Top" Task ; If the RB just processed is 
the last RB of the "top" task of the ter- 
minating tree, the RBREMOVE subroutine per- 
forms special processing for this last RB. 
(The last RB is not the ABEND routine's 
SVRB but is the RB pointed to by its RBLINK 
field. ) The last RB needs special process- 
ing to satisfy the needs of the supervi- 
sor's Exit routine, which purges all 
resources after the completion of ABEND16. 
The Exit routine expects that the last RB 
belonging to a completed task is a PRB. 
The RBREMOVE subroutine therefore converts 
its last-processed RB into a PRB and 
ensures linkage to the Exit routine by alt- 
ering certain RB fields. It converts the 
RB into a PRB by clearing the RBFTP sub- 
field of the RBSTAB field. To avoid mani- 
pulation of the contents directory by the 
CDEXIT subroutine of the Exit routine, the 
RBREMOVE subroutine clears the CDE pointer 
(RBCDE) . To permit dispatching of the Exit 
routine for the top task when ABEND16 pro- 
cessing is complete, the RBREMOVE subrou- 
tine removes any existing wait condition by 
clearing the RBWCF field. Also for this 
purpose it points the RB old PSW (second 
word of the RBOPSW field) to an SVC 3 
instruction in the communications vector 
table (CVT) at location CVTEXIT. The SVC 3 
instruction, when placed in execution by 
the Dispatcher, causes supervisor linkage 
to the Exit routine. 

PURGING THE LOAD LIST ; The resident Load 
List Purge routine (entered at location 
lEAQABL) releases load list elements and 
modules that were loaded for the selected 
task and are now no longer needed. This is 
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the same routine that performs a similar 
function for the EOT routine during a nor- 
mal task termination. The Load List Purge 
routine releases modules that were loaded 
for the selected task, but which were not 
released before the task was abnormally 
terminated. The modules would normally 
have been released by either the Delete SVC 
routine or the CDEXIT subroutine of the 
Exit routine. 



The Load List Purge routine examines 
each load list element in the load list, 
representing all modules that were loaded 
for the selected task. (The list origin 
for the load list is in the TCBLLS field of 
the TCB. ) The routine subtracts the 
responsibility count (number of load 
requests for each module) stored in its 
load list element, from the use/ 
responsibility count (total number of 
requests for the module) stored in the CDE 
for the module. Each load list element 
points to its associated CDE. The purpose 
of subtracting the responsibility count 
from the use/ responsibility count is to 
deteirmine the number of outstanding 
requests for the loaded module. 



The Load List Purge routine branches to 
the CDEXIT subroutine (location CDHKEEP) . 
The subroutine tests the number of out- 
standing requests for the module. If there 
is no outstanding request for the module, 
the routine tests the module's attributes. 
If the module is in the link pack area, 
control is returned immediately to the 
caller. If the module is not in the link 
pack area, is either reenterable or reus- 
able, and rollout has not been invoked, the 
routine sets the "release" flag in the 
module's CDE and the "purge" flag for the 
job pack queue. (These flags are tested by 
the GETMAIN routine to determine which 
module's space may be freed, if needed 
space is otherwise unavailable.) If the 
module is neither serially reusable nor 
reenterable, or if the current job step has 
invoked rollout, CDEXIT (via its CDDESTRY 
subroutine) removes the module's CDE from 
the job pack queue, and frees the space 
occupied by the module, its extent list, 
and its CDEs (major and minor). 



In a Model 65 Multiprocessing System, 
CDDESTRY tests the TCB, and, if it finds 
the Storage Reconfiguration completion 
code, bypasses the freeing of space occu- 
pied by the module. 

On return of control from the CDHKEEP 
subroutine, the Load List Purge routine 
frees the load list element. The process 
is repeated until all load list elements 
have been examined. 



PURGING DYNAMICALLY ACQUIRED MAIN STORAGE ; 
After control is returned from the Load 
List Purge routine, ABEND16 branches to the 
Subpool End-of-Task routine (SPEOT) , whose 
entry point is lEAQSPET. In a Model 65 
Multiprocessing System, the SPEOT routine 
is bypassed in the case of a Storage Recon- 
figuration entry. SPEOT is part of the EOT 
routine. The SPEOT routine releases sub- 
pools exclusively "owned" by the selected 
task and frees the associated subpool queue 
elements (SPQEs) . 

The SPEOT routine frees unshared sub- 
pools of main storage allocated to the 
selected task. The subpools are repre- 
sented by SPQEs, which have as their list 
origin the TCBMSS field of the selected 
TCB. The routine examines each SPQE on the 
queue. If an SPQE represents a shared sub- 
pool that may not yet be freed, the queue 
is updated (the "shared" SPQE is freed) to 
reflect the new unshared ownership of the 
subpool. If, however, an SPQE represents a 
subpool not shared with another task of the 
job step, the subpool and its SPQE are 
freed, via a branch to the FREEMAIN rou- 
tine. The SPQE list is updated, and the 
next element is examined. When all ele- 
ments have been examined, subpool 253, one 
of the numbers assigned to supervisor queue 
space, is explicitly freed since there is 
no SPQE for this subpool. 

If the selected task is the job-step 
task, a job-step termination must be occur- 
ring. In this case, besides freeing sub- 
pools and SPQEs, the SPEOT routine dequeues 
and frees CDEs and extent lists that 
describe modules in the job pack area (sub- 
pool pools 251 and 252) . Note that only 
reentrant modules (subpool 252) are left at 
this time if it is a job-step ABEND. These 
CDEs and extent lists are released during 
termination of the job- step task because 
the SPQEs for these two subpools are queued 
to the job step TCB and have not previously 
been released. The SPEOT routine checks 
the job pack area control queue ( JOBPACQ) , 
whose list origin is the TCBJQP field in 
the TCB, to discover if there is at least 
one CDE. If there is at least one CDE, the 
SPEOT routine branches to a part of the 
CDEXIT subroutine of the Exit routine 
(CDDESTRY) to free the remaining CDEs and 
their associated extent lists. 

RELEASING THE TASK CONTROL BLOCK (TCB) ; 
After freeing main storage and SPQEs for 
the selected task, ABEND16 follows either 
of two paths of processing, depending on 
whether the selected task is the top task 
of the tree. If the selected task is the 
top task, final processing is performed, as 
described in "Final Processing for the Top 
Task." But if the selected task is not the 
top task, ABEND16 sets the "completion" 
flag (TCBFC) in the selected TCB, to indic- 
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ate that the task has been terminated, 
removes the TCB from its queues, and frees 
its space. 

The dequeuing and freeing of the 
selected TCB is performed by two resident 
routines belonging to EOT: the "dequeue 
TCB" routine (DQTCB), whose address is 
lEADQTCB, and the "erase" routine (address 
lEAQERA) . The "dequeue TCB" routine 
removes the address of the selected TCB 
from the TCB queue. The reader may recall 
that the TCB queue consists of pointers 
connecting the TCBs of the system in the 
order of their dispatching priorities. The 
Dispatcher may examine this queue to deter- 
mine the next task whose current routine 
should be dispatched. Since the selected 
task is now terminated, its TCB must be 
removed from consideration by the 
Dispatcher. 

The ABEND routine does not contain spe- 
cial code in systems with the time-slicing 
feature. The EOT routine contains special 
code for time-slicing, and this code per- 
forms the preceding functions for ABEND16. 

The "erase" routine removes the selected 
TCB from its subtask queues, updating the 
TCBLTC and TCBNTC pointers in the next 
higher TCB of the tree. The first save 
area for the TCB is freed conditionally. 
The "erase" routine then branches to the 
FREEMAIN routine to free the space occupied 
by the selected TCB. After the release of 
a selected TCB, ABEND16 returns control to 
the "task select" subroutine to select the 
next higher level task of the tree of ter- 
minating tasks. The resources of the newly 
selected task are released in a manner 
similar to that described. 

FINAL PROCESSING FOR THE TOP TASK ; When 
the resources of the "top" task of the tree 
have been released, as indicated by a test 
after the SPEOT routine has returned con- 
trol, ABEND16 begins final processing for 
the top task. It loads the return register 
with a completion code that it obtains from 
the TCBCMP field of the top TCB. The 
parent of the top task may examine the com- 
pletion code, via an end-of-task exit rou- 
tine or a posted ECB, when its current rou- 
tine is dispatched. After placing the com- 
pletion code in the return register, 
ABEND16 causes linkage to the supervisor 
Exit routine by issuing an SVC 3 instruc- 
tion or, if the Storage Reconfiguration bit 
is set in a Model 65 Multiprocessing Sys- 
tem, invokes the Storage Reconfiguration 
ABEND module, ABEND20, via an XCTL. 

The supervisor Exit routine and the EOT 
routine provide final cleanup of the top 
task. The Exit routine removes the ABEND 
routine's SVRB from the top task's RB queue 
and frees its space. The Exit routine then 



branches to the Dispatcher to return con- 
trol to the current routine of the highest 
priority ready task. When the top task of 
the terminating tree is next dispatched, 
its RB old PSW causes control to be passed 
to an SVC 3 instruction in the communica- 
tion vector table (address CVTEXIT) . Con- 
trol is passed to the Exit routine, via 
Supervisor linkage, this time to remove the 
last RB from the top task" s RB queue. This 
RB is the one that was converted to a PRB 
by the RBREMOVE subroutine (see "Special 
Processing for the Last RB"). The Exit 
routine, after removing the "dummied" PRB, 
detects an end-of-task condition and 
branches to the EOT routine. 

The EOT routine, via its DQTCB and 
"erase" routines, removes the top TCB from 
the TCB queue and its subtask queues and 
frees its space. (If, however, an end-of- 
task exit routine (ETXR) or an ECB was 
specified when the top task was attached, 
the top TCB is not removed from its subtask 
queues.) The EOT routine next clears the 
"hew" TCB pointer (lEATCBP) to zero, indi- 
cating to the Dispatcher that it must 
search the TCB queue to find the highest 
priority ready task from among those that 
remain in the system. A task switch is 
thus ensured. The EOT routine returns con- 
trol to the Exit routine to free the space 
occupied by the last RB (the "dummied" PRB) 
of the top task. The Exit routine then 
branches to its Transient Area Refresh rou- 
tine to refresh (if necessary) a transient 
area block that was overlaid by the various 
modules of the ABEND routine. The Tran- 
sient Area Refresh routine, after perform- 
ing its processing, branches to the Dis- 
patcher to return control to the current 
routine of the highest priority task of 
those that remain in the system. 

Processing during ABEND20 (Entry Point 
IGCOKOIC) 

In a Model 65 Multiprocessing System, 
ABEND20 performs Storage Reconfiguration 
when a solid storage failure has occurred. 
It is invoked by ABEND16 if the Storage 
Reconfiguration bit, set by a Recovery 
Management Support routine, is on in the 
TCB. ABEND20 has two functions: 

• To execute a "dummy freepart" for the 
job step currently being processed by 
ABEND. This is done by inspecting the 
two bit indicator in the FSSEMAP for 
each 2K block within the boimdaries of 
the current region. (See Section 12, 
"Control Blocks and Tables" for a 
description of FSSEMAP.) Only those 
blocks which are not marked solidly 
failing are added to the dynamic FBQE 
chain. Those blocks which are not on 
the chain become logically unavailable 
to the system. 
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• To dequeue and free the partition queue 
element (PQE) which described the 
region being processed, and to issue a 
conditional GETPART for 52K. If 
storage is available, the new region is 
chained to the PQE of the already 
existing job step TCB by GETPART. 
ABEND20 then issues an SVC 3 instruc- 
tion which causes linkage to the super- 
visor exit routine. If storage is not 
available, this is indicated to the 
operator by a console message. ABEND20 
then issues an unconditional GETPART 
which places the task in a wait state 
until the storage becomes available. 



PERFORMING DAMAGE ASSESSMENT (DAR) 

The Damage Assessment Routine (DAR) 
receives control from ABEND when one of the 
following conditions occurs: 

• The termination of a task in "must com- 
plete" status. 

• The termination of a system task. 

• An invalid recursion. 



ing task has not been reinstated, control 
passes to DAR4. 

In the event of a primary DAR recursion, 
indicating that the DAR function failed 
during the writing of a dump, a further 
attempt to write a dump is bypassed. The 
operator is notified that the dump has 
failed, and control is passed to the appro- 
priate module, as described later. 

If there is no evidence of recursion, 
DARl sets a bit in the TCB of the failing 
task as a notification in case of future 
primary recursion. 

DARl then attempts to write a dump of 
main storage onto the SYSl.DDMP data set. 
If SYSl.DUMP is not available, the writing 
of the dump is bypassed and control passes 
to the next module. Otherwise, DARl issues 
an SVC 51 to pass control to the SVC DUMP 
routines. 

Exiting From DARl ; After either writing a 
dump of storage or an operator message as 
needed, DARl determines if further DAR pro- 
cessing is necessary or if control should 
be returned to ABEND: 



DAR alters the environment so that the 
ABEND routine or system processing can 
attempt to continue. Under certain circum- 
stances processing cannot continue; DAR 
then sets all tasks in the job step 
nondispatchable. 

The first module, DARl, gains control 
from ABENDl to test for recursions. If 
there are no recursions, DARl attempts to 
write a dump of main storage; failing that, 
a message is issued to the operator, and 
control passes to the next module. 



DAR2 processes tasks in 
status . 



"must complete" 



DAR2 - The terminating task is in "must 
complete" status. 

DAR3 - A system task is abnormally ter- 
minating. DAR3 determines if the task 
is eligible for reinstatement. 

DARU - The failing task's TCB is the 
job-step TCB, or a subtask whose job 
step is terminating. DARU sets the 
task permanently nondispatchable. 

ABENDl - In all other cases, ABENDl 
gains control, via an XCTL, to convert 
a subtask ABEND to a job-step ABEND. 



DAR3 attempts to reinstate tasks that 
are not in "must complete" status. 

DAR4 is entered for the sole purpose of 
setting tasks nondispatchable. After com- 
pleting processing, control passes to the 
Dispatcher . 

Processing during DARl (Entry Point 
IGCOLOIC) 

Damage Assessment Routine (DAR) Load 1 
receives control from ABENDl in the event 
of either an invalid ABEND recursion, a 
system task failure, or the failure of a 
task in "must complete" status. 

DARl first tests the TCB for a DAR 
recursion. In the event of a secondary DAR 
recursion, indicating that a dump of main 
storage may have been written but the f ail- 



Processinq during DAR2 (Entry Point 
IGCOMOIC) 

DAR2 is entered for tasks in "must com- 
plete" status. It searches the QELs to 
find the major and minor names of resources 
associated with the failing task. These 
names become input to the operator, who is 
requested to reply whether or not the 
resources are critical. When control is 
returned from the operator, the task is 
enabled. DAR2 must disable interruptions 
before continuing processing. 

If the resources are specified as crit- 
ical, control is passed to DAR4 which sets 
the failing task and subtasks nondispatch- 
able. They remain in this state for the 
duration of the current IPL after the 
operator has been informed that the ter- 
minating task failed to be reinstated. 
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If the resources are not recorded as 
critical, DAR2 releases the task from "must 
complete" status. The secondary DAR recur- 
sion bit is turned off to allow a chance 
for true DAR reinstatement. The word 
"ABEND" is put in the extended save area, 
and control returns to ABENDl to continue 
normal processing. 

Processing during DAR3 (Entry Point 
IGCONOIC) 

DAR3 receives control from DARl when the 
latter recognizes that the failing task is 
either the Master Scheduler or a subtask, 
and the task is not in "must complete" sta- 
tus. Task reinstatements are accomplished 
for system tasks as follows: 

MASTER SCHEDULER TASK ; The resume PSWs 
of all RES queued off the failing Master 
Scheduler Task are pointed to the SVC 3 
(EXIT) instruction in the CVT. The 
resume PSW of the highest level RB is 
redirected to an entry point within 
ABTERM (SCEDWAIT), where an SVC 6 (LINK) 
instruction is executed to provide lin- 
kage to the Scheduler Wait routine, lEE- 
VWAIT. The ECBs on which the Scheduler 
Wait routine waits are cleared- The 
operator is informed by a WTO message 
that the task has been reinstated. All 
information list entries for the task to 
be reinstated are purged. DAR3 then 
exits via an SVC 3 to reinstate the 
Master Scheduler task. 



control to the Communications Task Wait 
routine, lEECVCTB. A message is written 
to the operator, all information list 
entries for this task are purged, and 
DAR3 exits via an SVC 3. 

I/O RECOVERY MANAGEMENT SDPPORT TASK ; 
The PSWs of all RBs queued off the lORMS 
TCB are set to point to an SVC 3 
instruction in the CVT. The PSW of the 
top RB is modified to pass control to 
the entry point lORMSSVC in the RMS SVC. 
A reinstatement message is written to 
the operator, and all entries in the 
infomnation list pertaining to the task 
to be reinstated are purged. An SVC 3 
instruction is issued to begin the rein- 
statement process. 

ROLLOUT/ROLLIN TASK ; The rollout/rollin 
request is turned off and the task on 
whose behalf the rollout task is operat- 
ing is scheduled for abnormal termina- 
tion with a "DOA" completion code. DAR3 
then passes control to DAR4 to set the 
rollout task nondispatchable. 

If the failing task is a non-system 
task, the extended save area of the SVRB is 
cleared and the valid recursion flag is 
turned off. DAR3 then exits to ABENDl, via 
an XCTL, to continue teinnination 
processing. 

Processing during DARt (Entry Point 
IGCOPOIC) 



TRANSIENT AREA FETCH TASK ; The resume 
PSWs of all request blocks queued off 
the failing Transient Area Fetch TCB are 
pointed to the SVC 3 (EXIT) instruction 
in the CVT, while the highest level RB 
is modified to give control at entry 
point TBNOTFND in the Transient Area 
Fetch routine (IEAQTR33). A reinstate- 
ment message is written to the operator, 
and all information list entries are 
purged. DAR3 exits via an SVC 3 to 
reinstate the task. 

SYSTEM ERROR TASK ; The error flags in 
the SVCLIB DCB are cleared. If an RQE 
exists, the failing task's TCB is sche- 
duled for a "B06" ABEND completion code. 
The liBOPSW of the SIRB is set to point 
to an SVC 3 instruction. If an RQE does 
not exist, only the latter action is 
taken. DAR3 then issues a WTO instruc- 
tion to write the reinstatement message. 
All information list entries pertaining 
to this task are purged, and exit is via 
SVC 3. 

COMMUNICATIONS TASK ; The resume PSWs of 
all RBS queued off the failing Communi- 
cations Task TCB are pointed to the SVC 
3 (EXIT) instruction in the CVT, while 
the highest level RB is modified to give 



DAR4 is entered solely for the purpose 
of setting tasks permanently nondispatch- 
able. Entry to DARt is from any DAR 
module. If entry is from DARl, the ter- 
minating task must be set nondispatchable 
because of the existence of one of the fol- 
lowing conditions; 

• Task recursed invalidly through DAR. 

• Task failed reinstatement. 

• Task is a subtask whose job step is 
abnormally terminated. 

• Task is a job-step task which has 
recursed invalidly through the ABEND 
module, and is neither a special system 
task or a task in "must complete" 
status. 

Entry from DAR2 is caused by a terminating 
task that is in "must complete" status, and 
the systems operator has indicated that the 
resources are critical. Entry from DAR3 is 
caused by a rollout task that must be set 
nondis pat chable . 

Upon entry, DAR4 sets a recursion indi- 
cater and issues a WTO message to inform 
the operator that the terminating task 
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failed to be reinstated. If the indicator 
was already set when DAR4 was entered, the 
WTO message is bypassed to avoid a WTO/ 
ABEND recursion loop. The Subsystem Purge 
routine is entered to perform any necessary 
subsystem cleanup before the task is set 
permanently nondispatchable. If the GTF 
subsystem is the failing task, monitor call 
interruptions are disabled by the Subsystem 
Purge routine to prevent further system 
damage. 

The job-step TCB address of each ready 
task on the TC3 queue is then obtained, and 
the failing task, together with every task 
in the terminating tree, is set nondis- 
patchable. However, if the Master Sched- 
uler is failing, its subtasks are allowed 
to continue processing because they are 
tasks critical to the operation of the 
system. 

If the GTF trace function has been sus- 
pended, it is resumed via a HOOK macro 
instruction. This is done to ensure that 
tracing is resumed when ABEND has bypassed 
the ABDUMP function. 

The information list entries for each 
task in the terminating tree are purged. 
If the failing task is the Master Sched- 
uler, however, only its information list 
entries are purged. 

After setting all tasks in the terminat- 
ing tree nondispatchable, a branch entry is 
made to the Dispatcher. 



SPECIFYING A TASK ASYNCHRONOUS EXIT ROUTINE 

The STAE (Specify Task Abnormal Exit) 
macro instruction enables the user to spe- 
cify a STAE exit routine that is entered 
asynchronously if the task enters abnormal 
termination processing. The functions of 
the STAE service routine and the five 
ABEND/STAE interface routine (ASIR) modules 
are: 

The STAE Service Routine receives con- 
trol via an SVC 60 when the STAE macro 
instruction is issued. It checks the vali- 
dity of the STAE request, and creates, can- 
cels, or modifies a STAE control block 
(SCB) . 

ASIRO receives control from ABENDO to 
halt I/O operations that are in progress 
for the terminating task. 

ASIRl receives control from ASIRO. 
ASIRl establishes a work area and schedules 
the user-written STAE exit routine. 

ASIR2 receives control from ASIRl. 
ASIR2 returns to ABEND processing if a STAE 
retry routine is not requested. If a STAE 



retry routine is requested, ASIR2 invokes 
ASIR3. If the program using STAE is in 
supervisor mode and requests a STAE retry 
routine without a purge of the RB chain, 
ASIR2 invokes ASIR5. 

ASIR3 receives control from ASIR2. 
ASIR3 closes the data sets allocated to the 
RB of the RBs positioned between the STAE 
issuer up to and including the RB of the 
task scheduled for ABEND, and invokes the 
WTOR Purge routine. If any of the DCBs 
examined by ASIR3 is using BTAM, QTAM for a 
line group, BISAM, or QISAM, ASIR3 invokes 
ASIR4. If none of the above access methods 
are indicated, ASIR3 invokes ASIR5. 

ASIRU receives control from ASIR3. 
ASIR4 repeats the search for open data sets 
represented by DCBs using BTAM, QTAM for a 
line group, BISAM, or QISAM, closes these 
data sets, and invokes ASIR5. 

ASIR5 receives control from ASIR2, 
ASIR3, or ASIRiJ. ASIR5 sets dispatchable 
the subtasks related to the task using 
STAE, frees the storage occupied by the 
STAE control block, and schedules the STAE 
retry routine so that it is the next pro- 
gram executed. 

When the STAE macro instruction is 
issued, the resulting macro expansion 
places in register a code indicating the 
desired option (create, cancel, or over- 
lay), and, in register 1, the address of a 
parameter list. (See Section 12: "Control 
Blocks and Tables" for a description of 
this parameter list. ) The last instruction 
of the macro expansion is an SVC 60, which 
invokes the STAE service routine. 



Processing During the STAE Service Routine 
(Entry Point IGC00060+) 

The STAE service routine first examines 
the contents of the TCBNSTAE field of the 
TCB (displacement dec. 160). If the STAE 
has been issued in the STAE exit routine or 
in a STAE (subtask ABEND intercept) retry 
after a STAE or STAI exit ABEND (the high- 
order bit if the first byte of TCBNSTAE is 
on), an error code of eight is placed in 
register 15, and control is returned to the 
user. The STAE request is not serviced 
since STAE exit routine processing is 
already attempting to deal with an error 
situation. 

The routine then determines whether the 
STAE macro instiniction was issued with the 
TCB operand (only the ATTACH service rou- 
tine may use the TCB option). If so, the 
STAE service routine recognizes a subtask 
ABEND intercept (STAI) condition and pro- 
cessing continues with the test of exit and 
parameter list addresses below. 
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The STAE service routine next tests the 
contents of register to determine the 
option of the STAE request — to create, 
cancel, or overlay a STAE control block 
(SCB) . If register contains a zero (the 
create option) , the STAE exit routine 
address and the parameter list address 
specified in the STAE macro instruction are 
checked for validity. If either address is 
invalid an error code of twelve is placed 
in register 15, and control is returned to 
the user. 



The STAE service routine issues a condi- 
tional GETMAIN macro instruction to obtain 
16 bytes of storage for the SCB. The first 
word of the extended save area of the STAE 
SVRB is passed to GETMAIN to be used for 
the address of the storage that is 
obtained. If storage is not available, 
control is returned to the caller with a 
return code of four. If storage is avail- 
able, the STAE or STAI control block is 
created and placed on the SCB queue. A 
STAE SCB is placed immediately before the 
last STAE SCB created or, if there is no 
previous STAE SCB, after the last STAI SCB 
on the queue. A STAI SCB is always placed 
at the top of the SCB queue and will be 
propagated to all lower-level subtask TCBs. 
The address of the previous SCB and its 
STAE flag byte (zero if this is the first 
SCB created for the task) are placed in the 
first word, the address of the STAE exit 
routine is placed in the second word, and 
the address of the STAE exit routine para- 
meter list is placed in the third word. 
For STAE requests, the address of the 
user's RB is placed in the fourth word; for 
STAI requests, the address of the new sub- 
task's TCB is placed in the fourth word and 
the STAI indicator is set- This allows an 
exit to be scheduled for a parent task when 
one of its subtasks is scheduled for 
abnormal termination. 



If the XCTL option is requested in the 
STAE macro instruction (the high order bit 
of register 1 is on) and the TCB operand 
was not specified, the STAE service routine 
turns on the XCTL flag in the TCBNSTAE 
field. If this is a STAI request (the TCB 
operand is specified), the XCTL option is 
ignored. 

If the contents of register are not 
zero, or if register contains a zero but 
the STAE exit routine address is zero, 
either the cancel or the overlay option is 
being specified. The STAE service routine 
tests the TCBNSTAE field to determine if an 
SCB already exists. If it is zero, an 
error code of eight is placed in register 
15, and control is returned to the user 
since an SCB that does not exist cannot be 
canceled or overlayed. 



The STAE service routine next compares 
the RB address of the current SCB with the 
RB address of the program that is request- 
ing that the SCB be canceled or overlayed. 
If the RB addresses are not the same, a 
return code of sixteen is placed in regist- 
er 15, and control is returned to the user. 
This test prevents the unintentional 
destruction of another program's SCB. 

The STAE service routine now determines 
whether the STAE request is the cancel or 
overlay option. If register either con- 
tains a four or a zero with a STAE exit 
routine address of zero (the cancel 
option) , the address of the previous SCB 
and the TCB STAE flag byte (vrtiich are con- 
tained in the first word of the current 
SCB) are moved into the TCBNSTAE field. A 
FREEMAIN macro instruction is then issued 
to free the storage occupied by the can- 
celed SCB. 

If register contains an eight (the 
overlay option) , the STAE exit routine 
address and the STAE parameter list address 
are obtained and checked for validity. If 
either address is invalid, an error code of 
twelve is placed in register 15, and con- 
trol is returned to the user. If the STAE 
exit routine address and the parameter list 
address are valid, they are moved into the 
second and third words respectively of the 
current SCB. If the XCTL option is speci- 
fied, the XCTL option flag in the TCBNSTAE 
field is turned on. 

When the SCB has been successfully 
created, canceled, or overlayed, the STAE 
service routine returns control to the user 
with a return code of zero in register 15. 

Processing During ASIRO (Entry Point 
IGCOROIC) 

The ABEND/STAE Interface routine, load 
receives control from ABENDO when ABENDO 
determines that an SCB exists, or from 
ASIR2 when no retry is specified. ASIRO 
first branches to FREEMAIN to free the PIE 
if one is pointed to by the TCB. ASIRO 
tests the recursion bit of the TCBNSTAE 
field to determine if a STAE or STAI recur- 
sion has occurred. If this is not a STAE 
or STAI recursion, the current STAE SCB is 
located, and the STAE recursion flag is 
set. 

If the STAE user is in "must complete" 
status but is not a supervisor program, 
control is returned to ABENDO and abnormal 
termination processing continues. If the 
RB address in the current SCB cannot be 
found on the RB chain, that SCB is canceled 
and the next SCB on the chain is tested. 
If none of the RB addresses in any of the 
SCBs are on the RB chains, ASIRO returns 
control to ABENDO. If an SCB is found that 
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coni:ains an RB address on the RB chain, 
that SCB is used for normal processing. 

If the STAE user is a supervisor rou- 
tine, ASIRO sets a bit in the TCBNSTAE 
field. This bit is later referenced by 
SYNCH to ensure that the STAE exit routine 
will be scheduled in the same mode as that 
of the user. Asynchronous exits are 
allowed if the STAE user requested them. 
Processing continues with the determination 
of I/O in progress below. 

If ASIRO determines that this is a STAE 
or STAI recursion or if no STAE SCB is 
found, ASIRO searches the SCB queue for a 
STAI SCB that is indicated as not previous- 
ly processed by ASIRO. (If no unused STAI 
SCB is found or if a STAE SCB is found, 
ASIRO passes control to ABENDO to continue 
processing.) 

ASIRO processing of the valid STAE SCB 
or unused STAI SCB continues by determining 
if any I/O operations are in progress for 
the task that was scheduled for ABEND pro- 
cessing. If the TCBDEB field in the TCB 
contains a zero, no I/O operations are in 
progress. If the TCBDEB field is not zero, 
indicating that one or more data sets are 
open, and if a purge was requested by the 
user, ASIRO determines what type of purge 
was requested. If a purge with quiesce was 
requested, ASIRO sets the purge-quiesce 
flag in the TCBNSTAE field and invokes the 
Purge I/O routine with the quiesce I/O 
option. If the Purge I/O routine encoun- 
ters an ABEND situation while attempting to 
quiesce I/O, ABENDO is reentered. ABENDO 
tests the purge-quiesce bit and returns 
control to ASIRO. If the Purge I/O routine 
did not successfully quiesce I/O, or if a 
purge with halt was requested by the user, 
the halt I/O bit in the TCBNSTAE field is 
set to indicate that I/O is not restorable, 
and the Purge I/O routine is reinvoked with 
the halt I/O option. Upon return from the 
Purge I/O routine, if I/O operations were 
halted, or if the Purge I/O routine was not 
called, the first word in the extended save 
area (ESA) of the SVRB is set to zero. If 
the Purge I/O routine has successfully 
quiesced I/O, the address of the first I/O 
block (lOB) on the lOB restore chain is 
placed in the first word of the ESA by the 
Purge I/O routine for later restoration of 
I/O by the user. 

ASIRO passes control to ASIRl for normal 
exit processing. 

Processing During ASIRl (Entry Point 
IGCOSOIC) 

The ABEND/ STAE Interface routine, load 1 
establishes a work area and schedules the 
STAE exit routine. ASIRl attempts to get 
176 bytes of storage in subpool 250(0) for 



a register save and work area by issuing a 
conditional GETMAIN macro instruction. The 
request is conditional because the STAE 
processing can continue if storage cannot 
be obtained. If storage is not available, 
registers 0, 1, and 2 are initialized as 
parameter registers. A twelve is placed in 
register 0, the ABEND completion code that 
appears in the TCBCMP field in register 1, 
and the address of the STAE exit routine 
parameter list in register 2. 

If storage for the work area is 
obtained, the starting address of this area 
is placed in the ESA of the SVRB and in 
register 1 to be passed to the STAE exit 
routine. ASIRl initializes the work area 
with system status information at the time 
the ABEND was scheduled. The address of 
the STAE exit routine parameter list is 
placed in word 1; the ABEND completion code 
found in the TCBCMP field in word 2; the 
PSW at the time of the ABEND in words 3 and 
4; and the problem program PSW before the 
ABEND occurred, or zero if the task is a 
supervisor task, in words 5 and 6. Words 7 
through 22 contain the user's registers at 
the time of the ABEND. If the STAE user is 
a supervisor task, the RB address of the 
terminating program is placed in word 23, 
and zeros in words 2H through 26. If the 
STAE user is a problem program, the program 
name, or zero if the name cannot be found, 
is moved into words 23 and 2H, the address 
of the entry point of the terminating pro- 
gram into word 25, and zero into word 26. 
The starting address of the remaining 72 
bytes of the work area is placed in regist- 
er 13, to be passed to the STAE exit rou- 
tine and used as a register save area. 

Based on the results of the Purge I/O 
routine, ASIRl places in register a zero 
if I/O operations have been quiesced, a 
four if active I/O operations were halted, 
an eight if no I/O operations were in pro- 
gress at the time of the ABEND, or a six- 
teen if I/O intervention was bypassed. 

ASIRl effects the scheduling of the STAE 
exit routine by issuing a SYNCH macro 
instruction, which creates a PRB for the 
STAE exit routine. 

When STAE exit routine processing is 
finished, control is returned to ASIRl 
unless the STAE exit routine has requested, 
or encounters, an ABEND situation. ASIRl 
prohibits asynchronous interruptions and 
passes control to ASIR2. 

Processing During ASIR2 (Entry Point 
IGCOTOIC) 

The ABEND/STAE Interface routine, load 2 
first frees the last 76 bytes of the work 
area obtained by ASIRl (the user's register 
save area) via a FREEMAIN macro instruc- 
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tion. Register 3 is then examined to 
determine if the user indicated that all 
other STAI requests are to be ignored and 
ABEND processing is to be continued (com- 
pletion code of sixteen) . If so, the work 
area acquired by ASIRl is freed and control 
is passed to ABENDO via the XCTL macro 
instruction. If not, register 3 is 
examined to determine if the STAE user 
indicated that a STAE retry routine be 
scheduled. If the STAE user has not pro- 
vided a STAE retry routine (return code= 
zero) , ASIR2 frees the work area obtained 
by ASIRl. ASIR2 returns control to ASIRO. 

If register 3 contains a four or a 
twelve, the STAE user has requested that a 
retry routine be scheduled. The address of 
the STAE retry routine, passed to ASIR2 is 
register 10, and the address of the STAE 
retry routine parameter list, placed in the 
first word of the work area by the STAE 
exit routine, are checked for validity. If 
either is invalid, control is returned to 
ABENDO. If both addresses are valid, ASIR2 
passes information contained in the ESA to 
the other ASIR modules by placing the 
address of the first lOB on the restore 
chain or zero in register 7, the address of 
the work area or zero in register 8, the 
address of the STAE retry routine in 
register 10, and, if the STAE user is a 
problem program, the name of the program 
scheduled for ABEND in registers 11 and 12, 
and the entry point address of that program 
in register 13. ASIR2 then passes control 
to ASIR3 if retry with RB purge (return 
code=four) is specified or if a STAI retry 
(return code=twelve) is specified. 

If register 3 contains an eight, the 
STAE user has requested that a retry rou- 
tine be scheduled and that the RB chain not 
be purged. If the STAE user is not a 
supervisor program, as indicated by the 
supervisor flag in the TCBNSTAE field, and 
the user has supplied a work area, ASIR2 
frees the work area and returns control to 
ASIRO. If no work area is provided, ASIR2 
sets the RB old PSW to the address of an 
SVC 13 (ABEND) instruction and issues an 
SVC 3 (EXIT) instruction. Further STAE 
processing is not performed since the 
option of not purging the RB chain is 
reserved only for a supervisor program. 

If the STAE user is in supervisor mode, 
information is stored in the parameter 
registers, as described above. ASIR2 then 
sets the NORBPG flag in the TCBNSTAE field 
and invokes ASIR5 via the XCTL macro 
instruction . 

Processing During ASIR3 (Entry Point 
IGCOUOIC) 

The ABEND/STAE Interface routine, load 3 
receives control from ASIR2 when ASIR2 



determines that the RB chain must be purged 
and the STAE retry routine scheduled. Upon 
entry, ASIR3 stores the contents of the 
parameter registers 7, 8, 10, 11, 12, and 
13 in the ESA. 

ASIR3 determines v^ether the exit rou- 
tine is a STAI. If it is, the closing of 
data sets can be bypassed and the WTOR 
Purge routine can be called immediately 
because STAI SCBs are always associated 
with the first RB on the RB queue. If the 
exit routine is not a STAI, ASIR3 deter- 
mines if the RB address of the terminating 
program is the same as the RB address of 
the program that issued the STAE macro 
instruction. If the RB addresses are 
equal, the terminating program is the pro- 
gram that issued STAE, and no intervening 
RBs exist. In this case also, the routine 
that closes open data sets can be bypassed. 
To determine if any I/O operations are in 
progress for tasks represented by RBs that 
are between the RB of the program issuing 
STAE and the RB of the program scheduled 
for ABEND, the TCBDEB field is tested. If 
the TCBDEB field is zero, no I/O is in pro- 
gress, and the WTOR Purge routine can be 
called immediately. 

If the TCBDEB field is not zero and the 
RB addresses of the STAE issuer and the 
terminating task are not equal, ASIR3 must 
determine if any open data sets are asso- 
ciated with any of the intervening RBs. 
The search is accomplished by determining 
if the addresses of any of the DCBs on the 
related DEB chains are contained in the 
boundaries of a program represented by one 
of the intervening RBs. The first inter- 
vening RB tested is that of the program 
scheduled for ABEND. If an open DCB asso- 
ciated with one of the intervening RBs is 
found, ASIR3 determines from the DCBDSORG 
field if the access method being used is 
BTAM, QTAM for a line group, BISAM, or 
QISAM. If the DCB is using one of these 
access methods, the ISAM/TAM switch is set 
to indicate that ASIR4 must be the next 
module invoked to complete the close DCB 
processing. ASIR3 continues the search by 
examining the next DCB. 

If an access method other than BTAM, 
QTAM for a line group, BISAM, or QISAM is 
used for the DCB to be closed, ASIR3 must 
ensure that the user will not attempt to 
restore I/O events associated with this 
DCB. If no I/O operations were in progress 
when the Purge I/O routine was called in 
ASIRO, or if I/O operations were halted by 
the Purge I/O routine, I/O is not restor- 
able, and the DCB in question is closed 
without further processing. If the I/O 
operations are restorable, an I/O event 
related to the DCB to be closed may be 
queued on the lOB restore chain that was 
created by the Purge I/O routine. Depend- 
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ing on the access method used, ASIR3 deter- 
mines the addresses of the lOBs related to 
the DCB and compares them with the 
addresses of the lOBs on the restore chain. 
If they are equal, the lOBs on the restore 
chain are dequeued. The DCB is then closed 
via the CLOSE macro instruction. The 
search continues until all DCBs associated 
with intervening RBs have been closed and 
all lOBs related to these DCBs have been 
removed from the lOB restore chain. 

When the DCB search reaches the RB of 
the STAE issuer, or if this search was not 
necessary, ASIR3 invokes the WTOR Purge 
routine. The address of this routine is 
obtained from the secondary CVT. Upon 
return from the WTOR Purge routine, para- 
meter registers 7, 8, 10, 11, 12, and 13 
are initialized as previously described. 
If the ISAM/TAM switch is on, indicating 
that ASIR3 found one or more DCBs using 
BTAM, QTAM for a line group, BISAM, or 
QISAM during the DCB search, ASIR3 invokes 
ASIR4 which repeats the DCB search. If the 
switch has not been set, ASIR3 invokes 
ASIR5 via the XCTL macro instruction. 

Processing During ASIR4 (Entry Point 
IGCOVOIC) 

The ABEND/ STAE Interface routine, load U 
receives control from ASIR3 when ASIR3 has 
set the ISAM/TAM switch, indicating that, 
during the DCB search, one or more DCBs 
using BTAM, QTAM for a line group, BISAM, 
or QISAM were found. ASIR4 repeats the 
search made by ASIR3 and closes the DCBs 
that are related to RBs that exist between 
the RB of the STAE issuer and the RB of the 
program scheduled for ABEND processing. As 
in ASIR3, the RB of the program scheduled 
for ABEND is examined first. The access 
method of all DCBs on the DEB chains 
related to that RB are tested. If the 
related DCBDSORG field indicates that the 
DCB is using BTAM, QTAM for a line group, 
BISAM, or QISAM, ASIR4 determines if that 
DCB is related to the intervening RB. If 
it is, any I/O events related to that DCB 
are removed from the lOB restore chain. 
The DCB is then closed. The search con- 
tinues until all DCBs associated with 
intervening RBs have been tested, the 
related lOBs have been removed from the lOB 
restore chain, and the associated DCBs have 
been closed. The search ends when the RB 
of the STAE issuer is reached. ASIR4 
initializes the parameter registers and 
invokes ASIR5 via the XCTL macro 
instruction. 

Processing During ASIR5 (Entry Point 
IGCOWOIC) 

The ABEND/STAE Interface routine, load 5 
receives control from one of the following 
ASIR modules: 



• ASIR2 when STAE or STAI exit routine 
has requested that a STAE retry routine 
be scheduled but that the RB chain not 
be purged. (The user of STAE must be a 
supervisor program.) 



• ASIR3 when all DCBs associated with RBs 
that exist between the RB of the STAE 
issuer and the RB of the task scheduled 
for ABEND have been closed. 

• ASIRI when all DCBs (using BTAM, QTAM 
for a line group, BISAM, or QISAM) 
associated with RBs that exist between 
the RB of the STAE issuer and the RB of 
the task scheduled for ABEND have been 
closed. 

If the parent (originating) task is the 
Master Scheduler, all subtasks associated 
with the task must be set dispatchable. 
The ABEND wait flag (TCBABWF) is turned 
off. This flag was set earlier by ABTERM 
for all tasks which were to be terminated. 
The TCBLTC field, which contains the 
address of the last TCB on the subtask 
queue, is referenced to identify the asso- 
ciated subtasks. If the TCBLTC field is 
zero, no associated subtasks exist. If the 
field contains the address of a TCB, the 
Set Status routine is used to set all sub- 
tasks dispatchable. After all subtasks 
have been set dispatchable, the "task 
select" subroutine is called to select each 
subtask in the terminating job step in 
order. The ABDUMP nondispatchability flag 
(TCBNDUMP) is turned off, and the next sub- 
task is selected. 

If the NORBPG flag (set by ASIR2) in the 
TCBNSTAE field is not on, indicating that 
the user of STAE requested a purge of the 
RB chain, ASIR5 must purge the RBs on the 
chain that exist between the RB of the STAE 
issuer and the RB of the program scheduled 
for ABEND. The purge is accomplished by 
setting the RBOPSW of these RBs to point to 
an SVC 3 instruction located in the CVT. 
Since the STAE retry routine executes under 
the RB of the STAE user, a new RB need not 
be created. The RBOPSW of the STAE user is 
set to point to the address of the STAE/ 
STAI retry routine. 

If the NORBPG flag is on, the user has 
not requested a purge of the RB chain. An 
RB must be built for the STAE retry rou- 
tine. ASIR5 issues an unconditional requ- 
est for 32 bytes of storage via the GETMAIN 
macro instruction. The PSW is set to 
reflect the same mode as that of the STAE 
user, and the pointer fields in the RB and 
the TCB are set so that the STAE retry rou- 
tine is the next program executed after 
ASIR5 exits. The user's register 14 is set 
to point to an SVC 3 instruction in the 
CVT. 
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To determine if a work area was obtained 
by ASIRl, the work area address in the ESA 
of the SVRB is tested. If the address is 
zero, a work area was not obtained, and 
ASIR5 must initialize parameter registers 
to be passed to the STAE/STAI retry rou- 
tine. A twelve is placed in register 0, 
the ABEND completion code is register 1, 
and the address of the first JOB on the 
restore chain, or zero, in register 2. If 
a work area was established by ASIRl, it is 
reinitialized with system status informa- 
tion as it was in ASIRl except that the 
second word of the work area now contains 
the address of the first lOB on the restore 
chain, and the last word now contains an 
address to be passed to the Restore routine 
for restoring purged I/O. 



Before scheduling a STAE retry routine, 
the current SCB is removed from the queue 
of SCBs originating in the TCBNSTAE field. 
The address of the next SCB on the queue, 
or zero if there is no other SCB, is placed 
in the TCBNSTAE field or in the STAI SCB 
that immediately precedes the current SCB 
on the queue. ASIR5 then issues a FREEMAIN 
macro instruction to free the removed SCB. 



The ABTERM and prevent asynchronous exit 
flags in the TCB are cleared. The message 
Information List for Type-1 SVC routines is 
checked to see if it contains any entries 
for this TCB. If so, the entries are 
deleted. ASIR5 issues an SVC 3 instruction 
and gives control to the Dispatcher which 
schedules the STAE/STAI retry routine. 
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SECTION 11. SPECIAL FEATORES 



MODELS 91 Aim 195 DECIMAL SIMOLATOR 
(lEAXDSOO) ROUTINE 



The Decimal Simulator CIEAXDSOO) routine 
is provided to perform decimal arithmetic 
instructions since the decimal feature on 
the Models 91 and 195^ includes only the 
"EDIT" and "EDMK" instructions. 

Note: In this publication, the Decimal 
Simulator routine is also referred to as 
the simulator. 

The execution of the following instruc- 
tions is simulated by the Decimal Simulator 
routing : 



Instruction 



Assembler Operation 
Mnemonic Code 



Add Decimal 


AP 


X'FA' 


Subtract Decimal 


SP 


X'FB' 


Zero-and-Add Decimal 


ZAP 


X'F8' 


Multiply Decimal 


MP 


X'FC 


Divide Decimal 


DP 


X'FD' 


Compare Decimal 


CP 


X'F9' 



attempting to execute the instruction 
indirectly. If the simulation of the 
instruction execution is completed without 
error, the Decimal Simulator routine refers 
to the task control block (TCB) of the cur- 
rent task to determine where control is to 
be given. The possibilities are to return 
control to either the TESTRAN interpreter 
or the problem program containing the 
decimal instruction. 

If an error has occurred during the 
simulated execution of an instruction, the 
Decimal Simulator routine gives control 
back to the PFLIH routine indicated in 
Figure 11-2. 



SIMULATOR ORGANIZATION 

Figures 11-2 and 11-3 indicate the 
organization and flow of the Decimal Simu- 
lator routine. A discussion of the major 
routines in the simulator is given in the 
sections which follow. 

Simulator Control (DECENT) Routine 



RELATIONSHIP TO THE OPERATING SYSTEM 

Figure 11-1 indicates the relationship 
of the Decimal Simulator routines to the 
operating system. On the Models 91 and 
195, the attempted execution of a decimal 
instruction causes a precise interruption. 
This interruption causes control of the CPU 
to be given to the Program First-Level 
Interruption Handler (PFLIH) routine. 

After determining that the cause of an 
interruption was due either to a decimal 
instruction or to an EXECUTE instruction 
that addresses a decimal instruction, the 
PFLIH routine transfers control to the 
Decimal Simulator (lEAXDSOO) routine. The 
Decimal Simulator routine, operating in the 
supervisor state with all interruptions 
masked, interprets the instruction, checks 
it for validity, and performs operations 
that simulate the execution of the instruc- 
tion. At the completion of the simulation, 
control is given back to the CPU until 
another decimal instruction is encountered. 

A decimal instruction that causes an 
interruption may have been fetched directly 
from a problem program, or fetched remotely 
while the TESTRAN interpreter routine was 



^The Model 195 applies to both System/360 
and System/370 models. 



The Simulator control routine 
(hereinafter referred to as the control 
routine) performs the initialization of the 
Decimal Simulator routine. The control 
routine is entered from the Program First- 
Level Interruption Handler (PFLIH) routine 
when it is determined that a decimal 
instruction is to be simulated. The func- 
tions of this control routine are to: 

• Simulate address checking and protec- 
tion checking. 

• Simulate data checking, except for a 
decimal divide exception and a specifi- 
cation exception. 

• Direct the processing to the appropri- 
ate arithmetic routine. 

In performing the preceding functions, 
the control routine first obtains the size 
of main storage from the communications 
vector table. The main storage addresses 
of both the first operand and the second 
operand of the decimal instruction are 
determined, the length (in bytes) of each 
operand is computed, and the Decimal Simu- 
lator routine's work area is cleared. 

With the addresses established, the con- 
trol routine carries out the following 
simulated hardware checks in the order 
given. 
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MAIN STORAGE FOR MODELS 91 AND 195 



Nucleus 





The Program First-Level Interruption Handler (PFLIH) 
routine is given control when an attempt is made to 
execute a decimal instruction by either the problem 
program (la) or the TESTRAN interpreter (lb). 

The PFLIH routine analyzes the interruption, and, if 

a valid decimal instruction exists, control is given to the 

Decimal Simulator routine (2a). 



If an error exists, control is returned to 
the PFLIH routine (3c). Otherwise, after 
processing the instruction, the Decimal 
Simulator routine refers to the TCB (3) to 
determine if control should be returned to: 

(3a) the problem program 
(normal return) or 

(3b) the TESTRAN interpreter. 



3a H- 



if there has been an error, (entrance from (3c)) the PFLIH routine refers to the 
TCB (3) to determine if control should be returned to the TESTRAN interpreter (2b) 
or to other error-handling procedures. 



Supervisor Queue Area 



& 



TCB 



Dynamic Area 



©n_ 




TESTRAN Interpreter 



EX (AP) 





Problem Program 


(^< 


APOPl, OP2 


\!y 


(^ 







Link Pock Area 



I 



J 



Figure 11-1. Relationship of the Decimal simulator Routine (lEAXDSOO) to the Operating 
System 
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DECIMAL SIMULATOR ROUTINE 



DECASP 



Add/Subtract 
Decimal . 
Zero and Add 



Error 







TESTRAN 
Interpreter 



Problem 
Program 



PFLIH 



DECENj__ 

Monitor Simulator. 
Error Checking: 

a. Protection 

b. Addressing 
d. Data 



-0 



DECMP 



Multiply 
Decimal 



DECDP 



Divide 
Decimal 



Error 



Error 



■0- 



DECCP 



Compare 
Decimal 



G> 



ANALYZER/END 
Analyzer 



End 




I 



TESTRAN 
Interpreter 



Figure 11-2. Decimal Simulator (lEAXDSOO) Routine Organization and Flow of Control 
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i Routine 



Function 



H- 



Simulator 
Control (DECENT) 



Add/Subtract 
Decimal and 
Zero-and-Add 
Decimal (DECASP) 



H- 



Multiply Decimal 
(DEC MP) 



l~ 



Divide Decimal 
(DECDP) 



H- 



Compare Decimal 
(DECCP) 



^ 

Analyzer and End 



Main routine of the 
simulator: 

• Monitors overall 
operation. 

• Directs control 
to simulating 
routine once per 
execution of the 
simulator. 

• Checks for errors 
in data validity , 
protection, and 
overlap. 



Simulates execution 
of the following 
instructions : 

• Add Decimal 

• Subtract Decimal 

• Zero-and-Add 
Decimal 



Simulates execution 
of the Multiply 
Decimal instruction. 



Simulates execution 
of the Divide 
Decimal instruction. 



Simulates execution 
of the Compare 
Decimal instruction. 



-H 



Determines where 
control is to be 
returned after 
simulating a decimal 
instruction. 



Figure 11-3. Organization of the Decimal 
Simulator (lEAXDSOO) Routine 

1. The operand addresses are examined to 
determine if either (or both) is 
within the available storage limita- 
tions for the installation. If an 
address is outside the storage limit, 
an addressing exception occurs. 



restricted storage do not occur. (See 
below for details of protection 
check) . Since the results of most 
decimal operations are always placed 
in the storage location given by the 
first operand address of an instruc- 
tion, the check applied to a second 
operand address is only for a fetch of 
protection violation. Except for a 
Compare Decimal instruction, the first 
operand address of a decimal instruc- 
tion is checked for both a fetch and a 
store violation before the data is 
moved to the simulator's work area. 
With a Compare Decimal instruction, 
the first operand address is checked 
only for a fetch type of protection 
violation. If a violation occurs as a 
result of any of the preceding checks, 
a protection exception results. 

The operands addressed in the instruc- 
tion are then moved into the work 
area. (In the case of a Zero-and-Add 
Decimal instruction, only the second 
operand is moved into the work area, 
and the first operand is set to a plus 
zero.) 

Note; For all arithmetic operations, 
all data handling and movement is done 
in and/or between the operand work 
areas. 

Each operand is checked for a valid 
sign code (that is, decimal values 
10-15). An invalid sign code results 
in a data-check exception. 



Note: 



If the instruction is a ZAP 



instruction, the sign code check is 
made for the first operand by compar- 
ing against the value that has been 
pre-set to prevent an error condition. 

The digit codes of both the first and 
second operands are checked against 
the permissible codes for numeric-type 
information. Invalid digit codes 
result in a data-check exception- 
Only the second operand of a ZAP 
instruction is checked for validity. 



3. 



Using the data addresses and the 
length of the data fields, a check is 
made to determine if invalid overlap- 
ping has occurred. If it has, a data- 
check exception results . This check 
is not made for a Zero-and-Add Decimal 
(ZAP) instruction. 

If the program old PSW protection key 
is zero, a protection check is not 
made. Otherwise, the addresses of the 
left-most and the right- most bytes of 
the data are checked for fetch and/or 
store protection violations. This is 
to ensure that boundary violations of 



After performing the preceding checks 
for decimal arithmetic exceptions, the con- 
trol routine forces the sign code (in the 
work area) of both the first and second 
operands to EBCDIC format. These sign 
codes, together with the EBCDIC sign code 
for the result of the decimal operation are 
recorded in the work area of the Decimal 
Simulator routine. 

If, during the simulated hardware 
checks, an error condition (that is, a con- 
dition that would have caused an operation 
exception to occur) is detected, further 
checking by the control routine is ter- 
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mina-ted and control is iimnediately given to 
the Analyzer/End routine. Operands one and 
two of the decimal instruction are not 
changed. The old PSW indicates the appro- 
priate error condition as if the condition 
had been detected by the hardware itself. 

PROTECTION CHECK FEATURE ; To ensure 
against boundary violations, the complete 
storage areas occupied by both operand 1 
and operand 2 are checked in the order (1) 
through (U) as indicated in Figure 11-4. 

Simulator Routine for Add. Subtract, 
Zero-and-Add Decimal Instruction (DECASP) 

The DECASP routine is invoked by the 
Simulator Control (DECENT) routine if eith- 
er the Add Decimal, the Subtract Decimal, 
or the Zero-and-Add Decimal instruction has 
been encountered and if the DECENT routine 
has detected no error. Whenever it is 
given control, this routine simulates the 
processing of one of the three mentioned 
instructions . 

If the instruction is a Subtract Decimal 
instruction, the sign of the second operand 
is reversed to permit the processing to be 
carried out in the same manner as for an 
Add Decimal instruction. Then, for all 
three instructions, depending on whether 
neither, one, or both of the operands of 
the instruction are zero, the processing is 
performed with the following considerations 

• If the first operand is not zero, then 
each operand is converted to binary 
format. The two operands are added 
together if their signs are alike 
(after the reversal of the sign of the 
second operand as previously indi- 
cated) . If the signs are unlike, the 
smaller operand is subtracted from the 
larger operand. 

In the preceding processes, if the 
actual length of either operand is 
greater than five bytes (that is, the 
length code La or Li is greater than 
four) , the addition or subtraction is 
done in groups of four bytes at a time. 

At the completion of the arithmetic 
operations, the condition code is set 
in the PSW. If overflow has occurred 
in addition (as, for example, a result 
of an indicated operation to add two 
numbers of like signs) , an exit is made 
to the analyzer section of the 
Analyzer/End routine. Otherwise, the 
exit is to the end section of the 
Analyzer /End routine. 

• If the absolute values of the two 
operands are equal and the signs of the 



operands are opposite, a plus zero 
result is supplied. 

• If the first operand is zero, the 
second operand is moved to the first 
operand work area, and the condition 
code in the old PSW is set. If over- 
flow has occurred, an exit is made to 
the analyzer section of the Analyzer/ 
End routine. Otherwise an exit is made 
to the end section of the Analyzer/End 
routine. If the instruction is a Zero- 
and-Add Decimal (ZAP) instruction, the 
first operand has been previously 
forced to zero (see Simulator Control 
section). Therefore, the ZAP instruc- 
tion is treated at this point as an Add 
Decimal instruction. 

• If both operands are zero, the first 
operand is given a positive sign, and 
the condition code in the PSW is set to 
zero. 

Simulator Routine for Multiply Decimal 
Instruction (DECMP) 

The Simulator Control routine (DECENT) 
gives control to the DECMP routine if eith- 
er a Multiply Decimal or a Divide Decimal 
instruction has been encountered. If a 
specification exception exists for either 
of the following conditions, control is 
given to the Analyzer- End routine: 

• The actual length of the second operand 
is greater than eight bytes (that is, 
instruction length field, denoted by 
La, is greater than seVen) . 

• The actual length of the second operand 
is equal to or greater than the actual 
length of the first operand. 

After performing the preceding specifi- 
cation checks, control either is given to 
the divide decimal routine (DECDP) , which 
is discussed in the next section, if the 
instruction is a Divide Decimal instruc- 
tion, or remains in the DECMP routine for a 
Multiply Decimal instruction. 

The first operand of the Multiply Deci- 
mal instruction is examined to see if it 
has at least as many bytes of leading zeros 
as there are bytes in the second operand. 
If it does not have the required zeros, 
control is given to the data-check portion 
of the Analyzer/End routine. Otherwise, 
multiplication is performed according to 
one of the three following conditions: 

• If either operand is zero, the product 
field is cleared to zeros (if the first 
operand was not already zero) , and the 
proper sign is inserted. 
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(1) The address of the last byte specified 
in operand 1 is checked for both fetch and 
store protection.* (For a Compare Decimal 
instruction, only a fetch protection check 
is made.) If the check is satisfactory, step 

(2) is performed. Otherwise, a protection 
exception results. 



(2) The address of the first byte specified in operand 1 
is checked against the address of the last byte specified in 
operand 1 to see if both bytes are in the same 2K-byte 
storage block. If they are, a protection check is not made since 
the storage block has already been checked in step C^ Step 

(3) is then performed. If a different 2K-byte storage block 
is indicated, a complete fetch and store protection check is 
made.* (For a Compare Decimal instruction, only a fetch 
protection check is made.) If the check is satisfactory, 
step (3) is performed. Otherwise, a protection exception 
results. 




(3) The address of the last byte specified in 
operand 2 is checked against the address of the 
first byte specified in operand 1 to see if both 
bytes are in the same 2K-byte storage block. 
If they are, a protection check is not made since 
the storage block has already been checked in 
either step (1) or step (2). Step (4) is then 
performed. If a different 2K-byte storage block is 
indicated, a fetch protection check is made.* 
If the check is satisfactory, step (4) is performed. 
Otherwise, a protection exception results. 



(4) The oddrejs of the first byte specified in operand 2 is 
checked against the address of the last byte specified in 
operand 2 to see if both bytes are in the same 2K-byte 
storage block. If they are, a protection check is not made 
since the storage block has already been checked in either 
step (1), step (2), or step (3). If a different 2K-byte storage 
block is indicated, a fetch protection check is mode.* If 
the check rs satisfactory, the protection checking procedure 
is through, and the sign code checking is initiated. 
Otherwise, a protection exception results. 



* In the performance of the protection check, the protection key in the old PSW is compared with the protection key for the 
2K-byte block of main storage in which the address (of the data) is located. The 2K-byte storage block address is determined 
by setting to zero the eleven low-order bits of the address of the byte that is being checked. The remaining bits of the address 
indicate the storage block address. 



Figure 11- 4, Storage Protection Checking 
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• If the multiplicand (the first operand) 
does not exceed five bytes, both the 
multiplicand and the multiplier are 
changed to binary format (since the 
multiplicand may then be contained in a 
general register) , and the multiplica- 
tion is carried out using binary 
multiplication. 

• For all other cases (that is, both 
operands non-zero and multiplicand size 
over five bytes) , both the multiplier 
and the multiplicand are split into 
groups of four digits starting with the 
low-order sign positions. Initially, 
the 'lowest-order' group actually con- 
sists of three digits and a sign, but 
the sign is replaced by a zero for the 
actual processing. For multiplication 
purposes, each four-digit group is con- 
sidered to have a positive sign. The 
algebraically-determined sign for the 
final product is saved and affixed to 
the result. 

Each four-digit group is converted to a 
binary format, and all possible combi- 
nation of products of the four-digit 
groups are formed. (Note that each 
combination consists of one group from 
the multiplicand and one group from the 
multiplier.) From these products, par- 
tial sums are then formed according to 
the relative positions of the original 
four-digit groups. Beginning with the 
low-order partial sum, each partial sum 
is converted to decimal, and the low- 
order four digits (five digits for the 
first pairtial sum) of the sum are 
placed in the product field to the left 
of the digits already there. The 
remaining digits of the partial sum 
constitute a carry-over that is added 
to the next partial sum, the addition 
being performed in binary. In the case 
of the first (low-order) partial sum, 
the two zeros that had replaced the 
initial sign digits are truncated (that 
is, only three digits are moved to the 
product field) . 

After the last partial sum has been 
converted to decimal and moved into the 
product field, the sign of the product 
is inserted, and the multiplication is 
finished. Control is then transferred 
to the Analyzer/End routine. 

EXAMPLE OF MOLTI PLICATION BY DECIMAL SIMU- 
LATOR ; Assume a 7-byte multiplicand 
(operand 1) of 0000000099999C and a 4-byte 
multiplier (operand 2) of 9999999C. The 
four bytes of leading zeros in the multi- 
plicand satisfies the requirement of pro- 
viding space to contain the complete an- 
swer. The low-order hexadecimal character 
CO of operand 1 is replaced by a 0, and 
the resulting low-order four decimal digits 



(9990) are converted to binary format 
(2706i ). (Note: In this example, all 
binary formatted numbers are expressed in 
hexadecimal notation.] The next four digits 
(0099) of operand 1 are also converted to 
binary format (0063^ ). The remaining 
bytes in operand 1 remain as zeros. 



In a similar manner, for operand 2, the 
sign is replaced by a 0, and each group of 
four digits is converted to binary format. 
This results in the two groups of four 
digits: 270F (high-order) and 2706 (low- 
order). See Figure 11-5. 



The pertinent groups of digits from both 
operands can be arranged in the following 
manner for describing the next steps. 

The formation of the final product pro- 
ceeds in the following manner: 

• Sum A is converted to decimal with a 
plus sign: (05F2D424i6=099800100Cio) . 

• The two low-order hexadecimal charac- 
ters (OC) are dropped, and the next 
three digits (010) are stored in the 
operand 1 work area as the three low- 
order digits of the answer. 

• The remaining digits (09980) are con- 
verted back to binary (26FC) and are 
added to the initial Sum B to form a 
new Sum B, 
(06034AACi6+26FCj.6=060371A8i3 ) . 

• Sum B (060371A8i,6) is converted to dec- 
imal with a plus sign: (100889000Cj.o) . 

• The sign CO is dropped, and the low- 
order four digits (9000) are placed in 
the operand 1 work area as part of the 
final product. The product (at this 
point) is 9000010. 

• The remaining digits (10088) are con- 
verted to binary (2768) and are added 
to the initial Sum C to form a new Sum 
C, (000FlACDi6+2768i.6=000Fa235i6). 

• Sum C (000F4235i6) is converted to dec- 
imal with a plus sign: (0999989Ci.o > • 
Since this is the last partial sum in 
this example, the entire number 
(without the sign) is placed in the 
operand 1 area as the rest of the final 
product. Thus the final value in the 
operand 1 work area is 
09999899000010i.o- 

• The sign of the product is determined 
by the usual rules of multiplication 
and replaces the low-order digit in the 
operand 1 work area. In this example, 
the sign is plus CO. 
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Operand 1 (OPl) 



Operand 2 (0P2) 



-+- 

I 
-+- 



B 
0063 
270F 



I 
-+- 



2706 
2706 



1 

I 
1 

I 
^ 

I 
J 



The partial products are formed and stored as the indicated partial sums; 

OP2(A) X OPl(A) = 2706 x 2706 = Partial Sum A. 

OP2(A) X OPKB) = 2706 x 0063 = Partial Sum 31. 

OP2{B) X OPl(A) = 270F x 2706 = Partial Sum B2. 

Partial Sum Bl + Partial Sum B2 equals Partial Sum B. 

0P2(B) X OPICB) = 270F x 0063 = Partial Sum C. 

If a storage dump is taken at this point in the problem, the partial sums would appear 
as the values shown in the boxes that follow. 



Partial Sum C 

r 1 

I OOOFlACDio I 
L J 



Partial Sum B = (Partial B2 + Partial Bl) 

r n 

|06034AACi6 I 



Partial Sum A 



I 05F2D42IJ1.6 I 



Figure 11-5. Example of Multiplication by Decimal Simulation 



• The answer that is returned to the 
operand 1 area of the problem program 
is the 7 -byte value 0999989900001Cio - 

Simulator Routine for Divide Decimal 
Instruction (DECDP) 

Routine DECDP simulates the decimal 
divide feature for the Decimal Simulator. 
For a Divide Decimal instruction, the Mul- 
tiply Decimal (DECDMP) routine gives con- 
trol to the DECDP routine if the specifica- 
tion checks performed by the DECMP routine 
do not result in an error exit. 

Preceding the actual division, if the 
second operand is found to be zero, a 
divide check exception occurs, and the 
error section of the Analyzer/End routine 
is given control. 

To determine if the quotient will fit 
into the area (that is, the number of 
bytes, that is alloted to it, the divisor 
(the second operand) is aligned with the 
next to the left-most digit of the dividend 
(the first operand) . When so aligned, the 
divisor must be larger than the 'aligned' 
portion of the dividend if the quotient is 
to fit. If the quotient cannot fit, a 
divide-check exception occurs, and control 
is given to the error portion of the 
Analyzer/End routine. 

If the maximum length of the first 
operand is five bytes or less, the operands 
are converted to binary format and the 
division is performed in a general regis- 



ter, using the fixed-point division 
instruction. Otherwise, the division is 
carried out by repeated subtraction of mul- 
tiples of the divisor. Before the actual 
subtraction process begins, the divisor is 
left-aligned with the third digit from the 
left of the dividend. The divisor mul- 
tiples have the values, respectively, of 8, 
t, 2, and 1 times the divisor, and they are 
subtracted from the dividend at various 
stages in the process. Each multiple of 
the divisor corresponds to an appropriate 
bit to be entered in each 4-bit BCD quo- 
tient digit that is formed. If a multiple 
can be subtracted, its corresponding bit in 
the appropriate quotient digit is set to 1. 



After each quotient digit is formed, the 
divisor and its multiples are shifted right 
one digit, and the subtractions are per- 
formed again to form the next quotient 
digit. After each set of four divisor mul- 
tiples has been subtracted (or at least 
checked to see if it can be subtracted) 
from the dividend, the portion of the divi- 
dend that remains is referred to as a 'par- 
tial dividend. When the last quotient 
digit has been formed (as indicated by the 
divisor and its multiples being right- 
adjusted in their fields and the partial 
dividend being less than the divisor), the 
remaining contents of the dividend field 
are moved to the remainder field of the an- 
swer. The appropriate signs of the quo- 
tient and the remainder are inserted, and 
control is given to the end portion of the 
Analyzer/End routine. 
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EXAMPLE OF DIVISION BY DECIMAL SIMOLATOR ; 
Assume a six-byte dividend (operand 1) of 
00097000000C, and a four-byte divisor 
(operand 2) of lOOOOOOD. The dividend has 
been prefaced by leading zeros so that the 
pre-division check will indicate that the 
quotient can fit in the alloted area. When 
this check is performed, the alignment of 
dividend and quotient appears as follows: 



Dividend 00097000000C 
Divisor OlOOOOOOOOOC 

where the divisor appears with a leading 
zero and three low-order zeros for purposes 
of alignment. For comparison purposes dur- 
ing simulation, all signs are set positive. 
When aligned as shown, the divisor is 
greater than the dividend. This indicates 
that the quotient will fit in the alloted 
number of bytes. 

To begin the actual simulated division, 
the divisor is again shifted one digit- 
place to the right (toward the low-order 
end) , and multiples of the divisor are for- 
med. The alignment then looks like this: 
(The divisor and its multiples are given a 
plus ('C*i sign.) 

Dividend (D) 00097000000C 

Divisor First Multiple (DIM) OOIOOOOOOOOC 

Divisor Second Multiple (D2M) 00200000000C 

Divisor Fourth Multiple (DUM) OOUOOOOOOOOC 

Divisor Eighth Multiple (D8M) 00800000000C 

The divisor multiples are compared 
against the dividend in one of the three 
orders: 

• Fourth followed by Eighth followed by 
First if the eighth multiple is less 
than or equal to the dividend. 

• Fourth followed by Eighth if the fourth 
multiple is less than or equal to the 
dividend, followed by Second if the 
eighth multiple is greater thcin the 
dividend, followed by the First. 

• Fourth followed by Second if the fourth 
multiple is greater than dividend, fol- 
lowed by First. 

If the dividend is less than the first 
multiple, a zero (0) is entered as the 
corresponding quotient digit and all divi- 
sor multiples are shifted one place toward 
the low-order side (to the right) , and a 
new round of comparisons is undertaken. 

For each multiple that can be sub- 
tracted, the appropriate bit in the quo- 
tient digit is set to 1. Each round of 
comparisons seeks to locate the largest 
multiple (s) than can be subtracted from the 
dividend. 



Steps 1 through 3b in Figure 11-6 
illustrate the compare and shifting opera- 
tions that are performed and the formation 
of the quotient and remainder digits. 



Simulator Routine for Compare Decimal 
Instruction (DECCP) 

The comparison of the two decimal 
operands is made by the DECCP routine. If 
both operands are zero, they are considered 
equal regardless of their signs. If one 
operand is non-zero and the other one is 
zero, the non-zero operand is considered 
greater if it is positive, and it is con- 
sidered less if it is negative. 

If two non-zero operands are to be com- 
pared, each is extended in the work area 
(by adding leading zeros) to 31 digits plus 
the sign before comparison. The absolute 
values of the operands are than compared 
logically. The operand that is greater in 
absolute value is considered to be greater 
if it is positive but less if it is 
negative. 

If both operands have the same absolute 
value and sign, they are equal. If the 
absolute values are equal but the signs are 
different, the positive operand is consid- 
ered to be the greater- 
Control is given to the end portion of 
the Analyzer/End routine after the result 
of the comparison has been determined. 

Analyzer/End Routine 

The Analyzer/End routine is given con- 
trol to handle the termination procedures 
for the Decimal Simulator routine. If 
errors have been recognized by any of the 
preceding simulation routines, control is 
given to the analyzer (or error- handling) 
section of the routine. When the simula- 
tion of an instruction is completed 
successfully, or after the error-handling 
section has performed certain functions, 
control is given to the end section of the 
Analyzer/End routine. 

The analyzer section establishes the 
appropriate interruption code and places 
this code in the old PSW. In the case of a 
decimal overflow exception, bit 37 of the 
PSW is checked to determine whether the 
user or the operating system is to handle 
the error. If the decimal overflow is to 
be handled as a system error, the analyzer 
section retains control. Otherwise, con- 
trol is given to the end section. 

If there exists data that is not to be 
returned to the user, register addresses 
are moved to preclude the transfer of this 
data to the user's result area. 
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Dividend (D) 

Divisor First Multiple (DIM) 

Divisor Second Multiple (D2M) 

Divisor Fourth Multiple (D4M) 

Divisor Eighth Multiple (D8M) 



I Step 1 jstep 2 

^ +- 

00097000000C 
OOIOOOOOOOOC 3rd comp. 
00200000000C 2nd comp. 
00400000000C 1st comp. 
00800000000C 

Since D1M>D, a zero is 
entered as the first 
quotient digit. All 
multiples are shifted 
one digit to the right, 
and step 2 is per- 
formed. 



00097000000C 
OOOIOOOOOOOC 
00020000000C 
OOOUOOOOOOOC 1st comp. 
00080000000C 2nd comp. 

Since D8M<D, the second 
quotient digit's "8- 
bit" is set to 1. 
The D8M is subtract- 
ed from D to form a 
new D (value) for 
step 2a. 



jstep 2a 
-+- 



-H 



00017000000C 
OOOIOOOOOOOC 3rd comp. 
00020000000C 
00040000000C 
00080000000C 

since a given quotient 
digit cannot be greater 
than 9 and the second 
digit's "8-bit" is set 
to 1, the only compar- 
ison that can be made 
is with the DIM (corre- 
sponding to a "1-bit"). 
Since D1M<D, the second 
digit's "1-bit" is set 
to 1. Thus the second 
digit is 9 as a result 
of both the "8-bit" and 
the "1-bit" being set 
to 1. The DIM is sub- 
tracted from D to form 
a new D (value) for 
step 3. All multiples 
are shifted one digit 
to the right. 



Dividend (D) 

Divisor First Multiple (DIM) 

Divisor Second Multiple (D2M) 

Divisor Fourth Multiple (D4M) 

Divisor Eighth Multiple (D8M) 



Step 3 



00007000000C 
OOOOIOOOOOOC 
00002000000C 
OOOOUOOOOOOC 1st comp. 
00008000000c 2nd comp. 

Since D1M<D, and 
D8M>D, the third quo- 
tient digit's "4-bit" 
is set to 1. The DUM 
is subtracted from D 
to form a new D (value) 
for step 3a. 



jstep 3a 
-+- 



00003000000C 
OOOOIOOOOOOC 
00002000000C 3rd comp. 
00004000000C 
00008000000 

Since D2M<D, the 
third digit's "2-bit" 
is set to 1. The D2M 
is subtracted from D 
to form a new D (value) 
for step 3b. 



jstep 3b 

+ _ 

OOOOIOOOOOOC 
OOOOIOOOOOOC 4th comp. 
00002000000C 
00004000000C 
00008000000C 

since both the "4-bit" 
and the "2-bit" have 
been set for this quo- 
tient digit, the only 
comparison that can be 
made is with the DIM 
(see step 2a) . Because 
the D1M=D, the "1-bit" 
for this digit can be 
set to 1. Thus, the 
third digit is 7 as a 
result of the "4-bit," 
the ■2-bit," and the 
"1-bit" all being set 
to 1. The DIM is sub- 
tracted from D to give 
the value zero, which 
becomes the remainder 
in this example. (Both 
the dividend and the 
divisor multiples are 
now right-adjusted so 
no further shifting 
occurs and the division 
is complete.) 
j i i_ j ^ 

After step 3b in the preceding process has been completed, the three quotient digits that were formed 
are 097, and the remainder is zero. The sign of the remainder becomes the same as the sign of 
operand 1 (the dividend). In this example, the sign is plus CO. The sign of the quotient is plus 
if both operands have the same sign. Otherwise, the quotient sign is minus. In this example, the 
quotient sign is minus CD'). The final result is 097D0000000C. 



Figure 11-6. Example of Division by Decimal Simulator 
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The end section of the Analyzer/End rou- 
tine handles the return of control to the 
source from which the Decimal Simulator 
routine received control. For a successful 
simulation, the result obtained from the 
appropriate simulation routine is moved to 
the user's area. In the case of a decimal 
overflow condition which the user chooses 
to ignore, a result truncated to the length 
specified in the instruction is moved to 
the user's area. 



The end section gives control to the 
PFLIH routine if an error condition arises 
during the simulation process. (Note: If 
a decimal overflow condition is to be 
ignored, the Analyzer/End routine does not 
consider the overflow as an error condi- 
tion.) Otherwise, by testing the 'retum- 
to-TESTRAN' flag bit in the task control 
block, the end section determines the rou- 
tine (for example, problem program or TES- 
TRAN) to which control is to be returned. 



EXTENDED PRECISION FLOATING POINT SIMULATOR 

The extended precision floating point 
simulator provides each System/360 and 
System/370 CPU with the capability of pro- 
cessing all of the eight extended precision 
floating point arithmetic instructions. 
The System/360 Models 85 and 195 and the 
System/370 models with the extended preci- 
sion feature provide hardware support for 
all of the extended precision floating 
point instructions except the divide. The 
other System/360 models provide no hardware 
support of these instructions. Depending 
on the CPU, the supervisor simulates execu- 
tion of the divide instruction or all of 
the extended precision floating point 
instructions ; 



Instruction 
Add Normalized 

(extended) 
Divide 

(extended) 
Load Rounded 

(extended to long) 
Load Rounded 

(long to short) 
Multiply 

( long/ extended) 
Multiply 

( long/ extended) 
Multiply 

( extended) 
Subtract Normalized 

( extended) 



Assembler Operation 
Mnemonic Code 



AXR 



LRDR 



LRER 



MXD 



MXDR 



MXR 



SXR 



36 



25 



35 



67 



27 



26 



37 



♦The divide instruction is simulated by the 
DXR macro instruction. See the publica- 
tion Supervisor Services and Macro 
Instructions . 



RELATIONSHIP TO THE OPERATING SYSTEM 

The attempted execution of any of the 
eight extended precision floating point 
instructions that are not supported by CPU 
hardware causes a program interruption. 
The failing instruction is simulated by the 
supervisor if the user has provided the 
necessary linkage to the extended precision 
floating point simulator via the SPIE macro 
instruction (see Supervisor Services and 
Macro Instructions ) . The three modules 
which comprise the simulator are: 

• lEAXPSIM, which must be entered first 
to determine which of the other two 
modules is appropriate for the CPU. 

• lEAXPALL, which simulates the 8 
extended precision floating point 
instructions on System/360 CPUs that do 
not have hardware support for the 
instructions . 

• lEAXPDXP, which simulates only the DXR 
instruction on the System/360 Models 85 
and 195 and System/370 models. 

lEAXPSIM Processing 

The SPIE user routine passes in register 
1 the address of a pointer to a doubleword 
area. lEAXPSIM determines from the field 
CVTOPTA (offset X'182.7') in the CVT wheth- 
er the extended precision floating point 
feature is supported by CPU hardware. If 
so, lEAXPSIM moves the name of the module 
lEAXPDXR into the doubleword area; if not, 
the module name lEAXPALL is moved into the 
area. The user routine uses this name to 
bring the appropriate processing module 
into main storage. 

lEAXPALL Processing 

The user SPIE routine passes in register 
1 the address of a parameter list contain- 
ing the address of the PIE, the address of 
the register save area (containing the con- 
tents of the registers at the time of the 
interruption), a pointer to UOO-byte work 
area, and a pointer to a byte of main 
storage. If the byte of main storage is 
not zero, the validity of the low order bit 
of the result of the DXR instruction has 
not been ensured. lEAXPALL examines the 
operation code and register specifications 
of the failing instruction pointed to by 
the program check Old PSW. If any of these 
are invalid, an appropriate code and error 
indicator are returned to the caller. For 
the MXD instruction, lEAXPALL also issues a 
SPIE macro instruction to intercept any 
interruptions caused by invalid addressing. 

lEAXPALL then performs the necessary 
computation and indicates any exceptional 
conditions encountered diiring computation. 
For AXR and SXR instructions, the condition 
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code is set in the Old PSW in the PIE. A 
code in register 15 and an indicator in 
bits 28-31 of the PSW in the PIE are 
returned to the caller. 

Code Indicator Meaning 

00 unchanged Operation successful; no 
exceptional conditions. 

FF 1 Operation code did not 

specify an extended preci- 
sion operation to be pro- 
cessed by this module; no 
simulation attempted. 

4 Protection exception 
encountered during simula- 
tion of an MXD instruc- 
tion; operation 
suppressed. 

5 Addressing exception 
encountered during simula- 
tion of an MXD instruc- 
tion; operation 
suppressed. 

6 Specification exception 
encountered during simula- 
tion of an MXD instruc- 
tion; operation 
suppressed. 

C Exponent overflow encoun- 
tered; operation 
completed. 

D Exponent underflow encoun- 
tered; operation 
completed. 

E Significance exception 
encountered; operation 
completed. 

F Floating point divide 
exception encountered; 
operation is completed. 



lEAXPDXR Processing 

The user SPIE routine passes a parameter 
list identical to that passed to lEAXPALL 
except that the work area is 240 bytes. 
lEAXPDXR processing for the DXR instruction 
is identical to that in lEAXPALL except 
that only the divide instruction is 
handled. Any other operation code causes 
control to return to the caller with a code 
of X'FF' in register 15 and an interruption 
code of 1 in the PSW. 

If lEAXPDXR is used on a CPU without the 
floating point feature, an OCl ABEND code 
will result when an attempt is made to 
simulate an extended precision divide 
instruction. 



SYSTEM MANAGEMENT FACILITY 

The supervisor performs the following 
functions if the System Management Facility 
(SWF) feature has been selected at system 
generation: 

• Maintains a record of system wait time. 

• Assists in handling time limit expira- 
tions . 

• Counts and records the number of refer- 
ences to user data sets. 

• Controls the output limit for SYSOOT 
data sets. 

• Records the number of 2048-byte blocks 
of storage assigned to a user program. 



RECORDING SYSTEM WAIT TIME 

Whenever the Dispatcher puts the system 
in the wait state, it places the contents 
of the interval timer in the first word of 
a special save area, SYSWSAVE. When an 
external or input/output interruption ends 
the wait state, the interruption handlers 
call the SMF Wait Time Collection routine. 
This routine reads the interval timer again 
and compares its value with the value 
stored by the Dispatcher to determine the 
elapsed system wait time. It then adds 
this elapsed time to the value in the 
second word of SYSWSAVE, giving the accumu- 
lated wait time for the system. 

When a supervisor lO-minute timer 
interval expires, the Timer SLIH routine 
reads out the value in the second word of 
SYSWSAVE, which represents the total system 
wait time for the lO-minute interval. This 
value is added to a field in the system 
management control area, SMCAWAIT + 4. 

Each time the Step Termination routine 
of Job Management is entered, the total 
wait time recorded in the system management 
control area is checked. If it is nonzero, 
a system 10-minute wait record is 
generated. 



HANDLING TIME/OUTPUT LIMIT EXPIRATION 

Whenever a job, step, or wait time limit 
expires, the SMF Time Limit Expiration sub- 
routine of the Timer SLIH routine passes 
control to a user time limit expiration 
routine. The user routine determines 
whether or not to grant a time limit exten- 
sion. If an extension is granted, the SMF 
Time/Output Limit Expiration routine resets 
the TQE. If no extension is granted, the 
routine prepares for step termination in 
case of job/step time expiration, for 
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abnormal t.enninat.lon in case of wal-t time 
expiration. (The SMF Time/Output Limit 
Expiration routine is described in Section 
6, "Timer Supervision.") 



COUNTING REFERENCES TO USER DATA SETS 

Whenever a reference is made to a user 
data set, the EXCP Counting routine records 
the reference in an EXCP counter. There is 
a counter for each data set/device combina- 
tion. The counters are part of the TCT I/O 
Table segment of the timing control table. 



• The highest number of 2048-byte blocks 
that have been assigned to the the pro- 
gram at any one time (if the rollout 
feature is present) . 

If IBM 2361 Core Storage is included in 
the system, storage information is main- 
tained both for processor storage and for 
2361 Core Storage. 

The information is maintained by the SMF 
Storage routines, GMSMFCRE and FMSMFCRE. 
These routines are subroutines of the 
GETMAIN/FREEMAIN routine, and they are 
described in Section 5, "Main Storage 
Supervision. " 



CONTROLLING OUTPUT LIMIT FOR SYSOUT 

Whenever a reference is made to a SYSOUT 
data set, the EXCP Counting Routine checks 
for an output limit in the TCT I/O Table 
segment of the timing control table. If an 
output limit is specified, it is compared 
to the updated EXCP counters. 

If the output limit is exceeded, the SMF 
Output Limit Expiration routine gives con- 
trol to a user output limit routine. The 
user routine determines whether or not to 
increase the limit. If the increase is 
granted, the SMF Output Limit Expiration 
routine increases the output limit speci- 
fied in the TCT I/O Table. Otherwise, the 
routine prepares for abnormal termination. 



RECORDING STORAGE BLOCKS ASSIGNED TO USER 
PROGRAMS 

Whenever the main storage supervision 
routines allocate or release 2048-byte 
blocks of storage within a region assigned 
to a user program, the following informa- 
tion is recorded in the timing control 
table: 

• The highest address currently allocated 
from the bottom of the region. This 
address is called the "low water mark, " 
or LWM. 

• The lowest address currently allocated 
from the top of the region (the HWM — 
"high water mark") . 

• The smallest amount of space within the 
region that has been available to this 
program at any one time (the minimum 
difference between the LWM and the 

HWM). 

• The size of the region. 

• The number of borrowed 2048-byte blocks 
currently assigned to the program (if 
the rollout feature is present) . 



SMF ROUTINES 

A discussion of the two major SMF rou- 
tines, which perform the functions 
described above, follows. 

SMF Wait Time Collection Routine (lEAQWAIT) 

This routine, which resides in the nu- 
cleus, records system wait time. It is 
entered from the first-level interruption 
handlers whenever an external or input/ 
output interruption occurs. 

If the current TCB represents the system 
wait pseudo task, the system has been in 
wait condition. (Otherwise, control is 
simply returned to the calling interruption 
handler.) The SMF Wait Time Collection 
routine reads the interval timer. The 
timer value is compared with the value in 
the first word of a special save area, SYS- 
WSAVE. The value in SYSWSAVE was placed 
there by the Dispatcher when the system 
entered the wait condition. The comparison 
yields the elapsed system wait time. It is 
added to the value in the second word of 
SYSWSAVE, which gives the accumulated sys- 
tem wait time. 

After recording the accumulated system 
wait time, the routine returns control to 
the interruption handler that called it. 



SMF EXCP Counting Routine ( lEASMFEX) 

This routine, which resides in the nu- 
cleus, counts and records the number of 
EXCPs associated with user data sets. The 
count is maintained for all data sets re- 
corded in the TIOT of a problem program 
except SYSABEND, SYSUDUMP, JOBLIB, STEPLIB, 
TASKLIB, and PGM=*.DD data sets. It 
includes both direct EXCPs (SVC 0) and 
indirect EXCPs (those resulting from chan- 
nel end/abnormal end conditions or 
programmer-controlled interruptions). The 
routine counts references to the data sets 
by the Open, Close, and EOV routines. 
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Upon entry from lOS the EXCP Counting 
routine performs the following tests; if 
any test fails, control returns to the 
caller. 

• The TCBTCT field of the TCB is checked 
for the existence of a timing control 
table (TCT). 

• The TCTIOTBL field of the TCT is 
checked for the existence of an I/O 
extension of the TCT. 

• The DCBOFLGS field of the DCB is 
checked to assure that the DCB is eith- 
er open or in the process of being 
opened or closed. 

If all tests are successful, the routine 
searches the TCT I/O table segment of the 
TCT to find the correct EXCP counter 
(TCTDCTR). There is a counter for each 
combination of DCB and UCB. Counts are 
accumulated on a data set/device basis. 
(See Figure 11-7.) 

When the correct EXCP counter has been 
found, the routine adds 1 to the counter. 
Then, if the data set is not SYSOUT, the 
routine returns to the caller. 



data set. The routine passes control to 
the user output limit routine. It also 
passes a two^word parameter list containing 
the address of the JMR (job management 
region) and the address of the DCB. 

The user routine determines whether or 
not to grant an increase to the output 
limit. It returns control to the SMF Out- 
put Limit Expiration routine with a return 
code of for no increase, or 4 for an 
increase. If the return code is 4, regis- 
ter 1 contains the amount of increase to be 
granted. 

If an increase is granted, the SMF Out- 
put Limit Expiration routine adds the value 
of the increase to the output limit speci- 
fied in the TCT I/O table. If an increase 
is not granted, the routine schedules an 
abnormal termination of the program with an 
error code of 722. 



Note ; This routine (lEATLEXT) also handles 
time limit expirations. See Section 6, 



"Timer Supervision. 



If the reference was made to a SYSOUT 
data set, the routine checks the TCTOUTLM 
field of the TCT I/O table to determine if 
an output limit is specified. If an output 
limit is found, it is compared to the total 
of the EXCP count fields for each device 
associated with the data set. If the out- 
put limit is not exceeded, or if none was 
specified, the routine returns to the 
caller. 

Whenever an output limit is exceeded, 
one of the following actions is taken: 

• If exits are not allowed, the program 
is abnormally terminated with an error 
code of 722. 

• If exits are allowed, the routine 
creates an IRB/IQE representing the SMF 
Output Limit Expiration routine (lEAT- 
LEXT) . The Stage 2 Exit Effector is 
then entered to schedule the execution 
of lEATLEXT. 



SMF Output Limit Expiration Routine 
(lEATLEXT) 

This routine, which is resident in the 
nucleus, provides an interface with a user 
output limit routine ( lEFUSO ) . 



The routine (lEATLEXT) receives control 
from the EXCP counting routine when the 
output limit has been exceeded for a SYSOUT 



TRACING FACILITIES 



TRACE TABLE FACILITY 



The Trace Table facility is an optional 
feature that may be specified during system 
generation. If the Generalized Trace Faci- 
lity (GTF) is active, the Trace Table faci- 
lity is inhibited. The facility provides a 
record of system conditions at the time of 
the following system events; 

• SVC interruptions 

• External interruptions 

• Program interruptions 

• I/O interruptions 

• Start I/O operations 

• Dispatcher task switches 

Each of the above events is recorded in 
the supervisor trace table that is built in 
the nucleus by Trace routine lEAQTR. Most 
entries contain the old PSW, the contents 
of registers 0, 1, and 15, the current TCB 
address, and the time of the interruption. 
When the supervisor trace table is filled, 
the Trace routine overlays old entries with 
new entries beginning with the oldest 
entries. For the format of the supervisor 
trace table, refer to Section 12, "Control 
Blocks and Tables." 
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Trace Routine (lEAQTR) 

The Trace routine is resident in the nu- 
cleus and is loaded during nucleus initia- 
lization. The Trace routine is invoked by 
the SVC First-Level Interrupt Handler (SVC 
FLIH), the External FLIH, the Program Check 
FLIH, the I/O FLIH, and the Dispatcher. 
When entered, the routine records the event 
in the supervisor trace table. 



GENERALIZED TRACE FACILITY 

The Generalized Trace Facility (GTF) is 
invoked as a system task when the operator 
issues the START command. When GTF is 
active, the supervisor Trace Table facility 
(a system generation option) is inhibited 
until GTF is stopped. When starting the 
GTF task, the operator may select to record 
the trace data either in main storage or in 
the SYSl. TRACE data set on an external 
device (specified on the lEFRDER DD 
statement) . 



When the external storage option has 
been selected, the data recorded is more 
comprehensive and may include user supplied 
trace data. Also, the operator may specify 
events within an event class, such as: I/O 
interruptions from specific devices, only 
certain SVCs, etc. In a multiprocessing 
system, SSM (Set System Mask) interruptions 
(Event Class D) are also recorded. 



The GTF routines are entered from the 
interruption handlers and the Dispatcher 
when a HOOK macro instruction is issued. 
This instruction specifies the event to be 
recorded. The termination routines use the 
HOOK macro instruction to temporarily sus- 
pend GTF tracing, or to terminate GTF 
processing. 



For a more comprehensive discussion of 
the Generalized Trace Facility, refer to 
the publication Service' Aids Logic PLM . 



When the internal storage option has 
been selected, the data recorded for each 
event class is comparable to that recorded 
by the supervisor Trace Table facility. 
The event classes recorded are: 



Event 
Class 

2 

3 

4 

5 

D 



I/O interruptions 
SVC interruptions 
Dispatcher task switches 
Start I/O operations 
External and Program Check 
interruptions 
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TCT 



0(0) 



4(4) 



8(8) 



12(C) 



TCTIOTBL 



TCT I/O 
TABLE 



DCBTIOT 

DD Displacements 



UCB Address 



UCB Address 



Output Limit 

Extents Released 
Tracks Released 

UCB Address 



TCTDCTR (EXCP counter) 



TCTOUTLM 



TCTEXRLD 



TCTTKRLD 



TCTUCBP 



TCTSCTR 



TCTDCTR (EXCP counter) 




Address of 
TCT I/O Table 



Pointers to EXCP 
counters 



~ SEE NOTE BELOW 



Number of UCBs 
associated with data 
set (two in this 
example) 



NOTE: The end of the first section of the TCT I/O Table segment is marked by 
an entry of all zeros. The second section follows immediately. 



Figure 11-7. Example of TCT Pointers Used by EXCP Counting Routine 
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SECTION 12; CONTROL BIXXKS AMD TABLES 



The following control blocks, tables, and related areas are included in this section. 

Name of Table. Control Block, or Related Area Page 

ABDOMP Parameter List 335 

Allocated Queue Element (AQE) 325 

Block Extent List and Note List. 314 

Communications Vector Table (CVT) 279 

Contents Directory Element (CDE) 309 

Control and Relocation Dictionary Record. 320 

Control Record 318 

Descriptor Queue Element (DQE) 324 

Display Control Module (DCM) 337 

Dummy Partition Queue Element (DPQE) 328 

Entry Table 323 

Event Control Block (ECB) 302 

Fail Soft Storage Element Map (FSSEMAP) 347 

Free Block Queue Element (FBQE) 328 

Free Queue Element (FQE) 325 

GOVRFLB (Origin List for Main Storage Queues) 326 

Interruption Request Block ( IRB) 293 

Interruption Queue Element (IQE) 306 

Load List Element (LLE) 310 

Machine Check Record For SERO and SERl 364 

*.t : .,» /-i.o MO ^ r-«.n.«.j- w»i -oi .Anil. / r\/^-D \ "Sn ii 

Major Write Queue Element (WQE) (MCS) 357 

Major Write Queue Element (WQE) (Non-MCS) 356 

Message Information List 307 

Minor Queue Control Block (QCB) 304 

Minor Write Queue Element (WQE) (MCS) 360 

Minor Write Queue Element (WQE) (Non-MCS) 359 

Multiple- Line WTO Macro Expansion 362 

Multiprocessing Communications Vector Table (MPCVT) 346 
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Name of Table, Control Block, or Related Area (Continued) Page 

Parameter List Element for the ENQ/DEQ Routines 303 

Partition Queue Element (PQE) 327 

Partitioned Data Set Directory Entry 310 

Program Fetch Buffer Table 317 

Program Fetch work Area 316 

Program Interruption control Area (PICA) 300 

Program Interruption Elonent ( PIE) 300 

Program Request Block (PRB) 296 

Queue Element (QEL) 305 

Relocation Dictionary (RLD) Record 319 

Reply Queue Element 329 

Reply Queue Element for MCS 329 

Request Queue Element (RQE) 308 

Resident Display control Module (RDCM) 337 

Rollout I/O Queue Element (RIQE) 328 

Sample Dump 368 

Scatter Extent List. 313 

Scatter Translation Record 315 

Secondary Communications Vector Table (SCVT) 333 

Segment Table 321 

STAE control Block (SCB) 301 

STAE Parameter List 301 

Storage Utilization Block (SUB) 366 

Subpool Queue Element (SPQE) 324 

Supervisor Request Block (SVRB) — for Nonresident Routine 292 

Supervisor Request Block (SVRB) — for Resident Routine 291 

SVC Purge Parameter List 330 

SVC Table 278 

System Interruption Request Block (SIRB) 295 

Task Control Block (TCB) 283 

Time-Slice Control Element (TSCE) 336 

Timer Queue Element (TQE) 331 



276 



Name of Table, control Block, or Related Area (Continued) Page 

Trace Table (Uniprocessing Systems) 297 

Trace Table (Multiprocessing Systems) 298 

Transient Area Control Table (TACT) 299 

Transient Display Control Module (TDCM) 340 

Unit Control Module (UCM) Base 348 

Unit Control Module (Prefix for Multiple Console Support) 349 

Unit Control Module (Prefix for UCM Extension) 349 

Unit Control Module Text and EIL Areas 353 

Unit Control Module Entry Individual Device Map 351 

Vary Queue Element (VQE) 347 

Write Queue Element (WQE) for Multiple Console Support (Single- line WTO) 354 

WTO/R Macro Expansion 361 
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SVC TABLE 




Enfries for 
resident SVC 
rouKnes - 4 

TYPE 1 



1 byte 



00 ZEROS 



3 byte 



MAIN STORAGE ADDRESS 



Entries for 
resident SVC 
routines - 4 

TYPE 2 



10 ZEROS 



MAIN STORAGE ADDRESS 



Entries for 
transient SVC 
routines - 4 

TYPE 3 and 4 





12 bits » 


-« 18 bits ^ 


II 


2 

LENGTH 


RELATIVE TRACK AND 
RECORD ADDRESS 








, 







Note: '00' flag in tv/o high-order bits Indicates resident type 1 routine 

'10' flog in tv/o high-order bits indicates resident type 2 routine 

'11' flag in tv/o high-order bits indicates transient (non-resident) 
type 3 and 4 routines 



278 



COMMUNICATIONS VECTOR TABLE (CVT) 



The coimtiunications Vector Table provides the means whereby nonresident routines may 
refer to information in the nucleus of the control program. The CVT is part of the resi- 
dent nucleus. 

The symbolic displacements below are generated in nonresident routines by use of the 
CVT macro instruction. The address of the first location of the CVT is placed in main 
storage location hexadecimal 10 during nucleus initialization. 



Field Description, Contents. Meaning 

Reserved. 

CPU model number in decimal. 

Release number in EBCDIC. 

Pointer to addresses for next and current TCB. 

Address of Stage 2 Exit Effector. 

Address of DCB for SYSl.LINKLIB. 

Address of work queue control blocks. 

Address of buffer for Resident Console Interrup- 
tion routine. 

Address of lOS appendage table. 

Entry-point address of Validity Check routine. 

Entry- point address of routine for converting 
relative track address to absolute. 

Entry- point address of routine for converting 
absolute track address to relative. 

Address of channel and control unit section in 
UCB lookup table. 

Address of UCB address list section in UCB lookup 
table. 

Entry-point address to Stage 3 Exit Effector for 
system error routines. 

Address of system residence volume entry in UCB 
lookup table. 

Entry- point address of ABTERM routine. 

Current date in packed decimal. 

Address of master common area. 

Address of I/O device characteristic table. 

Address of Error Interpreter routine. 

Address of I/O control blocks used by DAR; zero 
if function inoperative. 

Reserved. 



Offset 


Bits 


and 


Field 


Dec 


Hex 


Byte 


Pattern 


Name 


-8 


-8 


2 






-6 


-6 


2 




CVTMDL 


-4 


-4 


4 




CVTRELNO 








4 




CV'iTCBP 


H 


4 


4 




CVTOEFOO 


8 


8 


4 




CVTLINK 


12 


C 


4 




CVTJOB 


16 


10 


4 




CVTBUF 


20 


14 


4 




CVTXAPG 


2H 


18 


4 




CVTOVLOO 


28 


IC 


4 




CVTPCNVT 



32 



36 



40 



44 



48 



20 
24 
28 
2C 
30 



52 


34 


4 


56 


38 


4 


60 


3C 


4 


64 


40 


4 


68 


44 


4 


72 


48 


4 



76 



4C 



CVTPRLTV 

CVTILKl 

CVTILK2 

CVTXTLER 

CVTSYSAD 

CVTBTERM 

CVTDATE 

CVTMSLT 

CVTZDTAB 

CVTXITP 

CVTDAR 

CVTOFNOO 
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80 


50 


2 


82 


52 


2 


8a 


5H 


4 


88 


58 


4 



92 



108 



5C 



96 


60 


4 


100 


64 


4 


104 


68 


4 



6C 



112 


70 


4 


116 


74 


1 

1.. 

XXX. x.xx 


117 


75 


3 


120 


78 


4 


124 


7C 


4 


128 


80 


4 


132 


84 


4 


136 


88 


4 


140 


8C 


4 


144 


90 


4 


148 


94 


4 


152 


98 


4 


156 


9C 


4 


160 


AO 


4 


164 


A4 


4 


168 


A8 


4 


172 


AC 


4 


176 


BO 


4 


180 


B4 


2 


182 


B6 


1 



CVTEXIT An SVC 3 instruction. 

CVTBRET A BCR 14,15 instruction. 

CVTSVDCB Address of DOB for SYSl.SVCLIB data set. 

CVTTPC Address of pseudo clocks for Timer routine (SHPC 
first) . 

CVTPBLDL Branch and link entry-point address to BLDL 
routine. 

CVTSJQ Reserved. 

CVTCUCB Address of table with console UCB addresses. 

CVTQTEOO Address of Timer Enqueue routine (lEAQTEOO) in 
Timer SLIH. 

CVTQTDOO Address of Timer Dequeue routine (lEAQTDOO) in 
Timer SLIH. 

CVTSTB Address of I/O device statistics table. 

CVTDCB Operating system configuration. 

CVT4MS1 Uniprocessing. 
CVT4MPS Multiprocessing. 
Reserved. 

CVTDCBA Address of DCB for SYSl.LOGREC data set. 

CVTIOQET Address of I/O request element table. 

CVTIXAVL Address of lOS Freelist pointer. 

CVTNOCB Lowest storage address not in nucleus. 

CVTFBOSV Address of Program Fetch routine. 

CVTODS Entry-point address of Dispatcher. 

CVTILCH Address of logical channel word table. 

CVTIERLC Address of logical channel error queue. 

CVTMSER Address of Master Scheduler resident data area. 

CVTOPTOl Branch entry-point address of Post routine. 

CVTTRMTB Address of QTAM terminal table. 

CVTHEAD Address of highest priority TCB on TCB queue. 

CVTMZOO Highest storage address in machine. 

CVTIEFOO Reserved. 

CVTQOCR Address of a pointer to the Graphics Job Proces- 
sor parameter list. 

CVTQMWR Address of SYSOUT CDA area. 

CVTSNCTR Data set sequence number. 

CVTOPTA Flags . 
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1... 
1.. 
I. 
.1 



183 B7 



1 

X. .X 







••Xa •■•• 






XX. X XXXX 


184 


B8 


4 


188 


BC 


4 


192 


CO 


4 


196 


C4 


4 


200 


C8 


4 


204 


CC 


4 


208 


DO 


4 


212 


D4 


2 


214 


D6 


2 


216 


D8 


4 


220 


DC 


4 


224 


EO 


4 


228 


E4 


1 

.XXX XXXX 


229 


E4 


3 


232 


E8 


4 


236 


EC 


1 



00. 
01. 
10, 

11. 
1 



237 


ED 


3 


240 


FO 


1 

-L««* •••• 

.XXX XXXX 



CVTCCH CCH option present. 

CVTAPR APR present. 

CVTDDR DDR present. 

CVTNIP NIP processing. 

CVTHIAR Main storage hierarchy support operative. 

CVTASCII ASCII option present. 
Reserved . 

CVTOPTB Flags . 

CVTTOD CPU has Time-of-Day clock. 
Reserved. 

CVTQCDSR Address of CDE search routine. 

CVTQLPAQ Address of first CDE in LPA queue. 

CVTMPCVT Address of M65MP secondary CVT. 

CVTSMCA Address of system management facilities control 
area. 

CVTABEND Address of secondary CVT. 

CVTUSER Field available to user. 

CVTMDLDS Reserved. 

CVTQABST An SVC 13 instruction. 

CVTLNKSC Reserved. 

CVTTSCE Address of first time-slice control element 
(TSCE) . 

CVTPATCH Address of 200-byte patch area in the nucleus. 

CVTRMS Address of RMS work area. 

CVTTSFLG Time sharing option flags. 

CVTTSRDY TSO ready and initialized. 
Reserved. 

CVTTSCVB Address of time sharing CVT. 

CVTOSCRl Address of Sector Calculation routine for RPS. 

CVTGTFST GTF status indicator flags. 

CVTGTFIN GTF inactive. 

CVTGTFSR GTF Starting. 

CVTGTFSP GTF Stopping. 

CVTGTFAC GTF active. 

CVTSTATE GTF in control. 

CVTMODE GTF in external mode. 

CVTFORM ABDUMP to format trace data. 

CVTUSR USR trace. 

CVTMCTYP MC instruction valid. 
Reserved. 

CVTCMT Address of class mask table. 

CVTTCMFG TCAM flags. 

CVTTCRDY TCAM running. 
Reserved. 
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241 


Fl 


3 


244 


F4 


17 


261 


105 


3 


264 


108 


5 


269 


lOD 


3 


272 


110 


1 


273 


111 


3 



CVTAQAVT Pointer to address of TCAM vector table. 

Reserved. 
CVTPURGA Address of Subsystem Purge routine. 

Reserved. 
CVTQMSGA Address of type-1 SVC communication area. 

Reserved. 
CVTDMSRA Address of Open/Close/BOV supervisory routine. 
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TASK CONTROL BLOCK 



Offset 


Bits and 


Dec 


Hex 
-20 


Byte Pattern 


-32 


8 


-24 


-18 


8 


-16 


-10 


8 


-8 


-8 


8 








1 


1 


1 


3 


H 


4 


1 


5 


5 


3 


8 


8 


1 


9 


9 


3 


12 


C 


1 


13 


D 


3 


16 


10 


4 


20 


14 


1 



21 15 
24 18 



25 19 

28 IC 

29 ID 



1... 

..1. 
.x.x 



0000 0000 
nonzero 

3 

1 

JxaJUL • • • • 

.... 0000 



Byte 



Field 
Ncune 

TCBFSSO 

TCBFRS2 

TCBFRS4 

TCBFRS6 

TCBRBP 

TCBPIE 

TCBDEB 

TCBTIO 
TCBCMP 
TCBFLTRN 



TCBTCP 

TCBTRN 
TCBNROC 



TCBMSS 
TCBPFK 

TCBFLGS 
TCBFA 



Field Description, Contents, Meaning 

Save area for floating point register 0. 

Save area for floating point register 2. 

Save area for floating point register 4. 

Save area for floating point register 6. 

Zero. 

Address of last RB on RB queue. 

Zero. 

Address of FIE. 

Zero. 

Address of last DEB on DEB queue. 

Zero. 

Address of task I/O table. 

Task completion code. 

Flags. 

Both TESTRAN and decimal simulator programs are 

being used on a Model 91. 

Suppress taking checkpoints for this step. 

Job-step TCB: this is a graphics foreground job 

or the Graphics Job Processor. 

TCB for 7094 Emulator task on Model 85. 

Time- shared task under control of TEST command 

processor. 

OLTEP cleanup. 

Reserved. 

Address of TESTRAN control area. 

Job-step TCB; rollout eligibility. Initialized 
by Attach routine from input parameters provided 
by job-step's initiator. Count increased by ENQ 
routine; decreased by DEQ routine; tested by TES- 
TSTEP routine of rollout module. 

Job step may be rolled out. 
Job step may not be rolled out. 

Address of last SPQE on SPQE queue. 

Storage protection key. 

Storage protection key. 
Must be zeros. 

Flags . 



Indicates that abnormal termination, performed by 
the ABEND routine, is in progress for this task. 
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1 TCBFE Indicates that normal termination, performed by 

the EOT routine, is in progress for this task. 
.1 TCBFERA Indicates that the Erase Phase routine is to be 

entered when the ABEND routine is again executed 

for this task. 
..1 .... TCBGTOFM Indicates that GTF trace is suspended. 
... 1... TCBPDUMP Indicates that no abnormal termination dumps are 

to be taken for any task within the job step. 

Set in the job-step TCB. 
... .1.. TCBFT Indicates that this task is currently the top 

task of a tree of tasks being abnormally 

terminated. 

Indicates that an abnormal termination dump has 

been performed for this task. 

Prohibits asynchronous exits from being scheduled 

for this task. 



•••• ««Xa 


TCBFS 


• «•■ avaX 


TCBFX 


Byte 1 
x««« •••• 


TCBFOINP 


• J.«« •••• 


TCBFSTI 



TCBFRA 



1 — 


TCBFSMC 


. 1... 


TCBFJMC 


. .1.. 


TCBFDSOP 



..1. 



Indicates that the dump data set for the job step 
is being opened. 

Indicates that a job step interval requested by 
an initiator has expired or the job step has been 
cancelled by the operator. (Set in the job-step 
TCB.) 

Meaningful only in a job-step TCB. Initialized 
by the Attach routine from input parameters pro- 
vided by job step's initiator. 

= job step cannot cause rollout. 

1 = job step can cause rollout. 

Indicates that this task is in "system must com- 
plete" status. 

Indicates that this task is in "job step must 
complete" status . 

Indicates that the ABEND routine has previously 
opened the dump data set for this job step. (Set 
in the job-step TCB. ) 

TCBFETXR Indicates that an end-of-task exit (ETXR) routine 
is to be scheduled for the task that attached 
this task. 

TCBFTS Indicates member of time-slice group. 



Byte 2 






TCBFSM 



TCBFRI 



I • • • J^XJi. • 



TCBABTRM 



TCBSXPKO 



TCBDWSTA 



Indicates that the RB old PSW for all programs 
executed as part of this task should be set to 
supervisor state. 

"Rollout Invoked" flag. Meaningful only in a 
job- step TCB. 

= job step has not invoked rollout. 

1 = job step has had one or more main storage 
requests satisfied from outside its region (via 
the rollout mechanism). "Borrowed" space is 
still allocated to the step. 

Prevents multiple scheduling of the ABEND routine 

by the ABTERM routine. Also indicates that the 

operands of the ABEND macro instruction have been 

saved in the TCBCMP field. 

RB issued by STAE exit routine was in protection 

key 0. 

Reserved. 

Indicates that this task was detached with the 

STAE=YES option. 



Byte 3 






TCBNDUMP Indicates that the ABDUMP routine has made this 
task nondispatchable while it is displaying 
dynamic queues. 

TCBSER Indicates that this task is nondispatchable while 
the SERl routine is being executed for this task. 
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..1. 


• • • • 


TCBRQENA 


• * • a. 


1... 


TCBOXNDV 


. ..X 


• x« • 




• k • • 


..1. 




« • • •- 


...1 


TCBONDSP 


Byte 
1... 


4 

« • • • 


TCBFC 


.1.. 


• • a • 


TCBABWF 






34 


22 


1 


35 


23 


1 


36 


24 


1 


37 


25 


3 


40 


28 


1 


41 


29 


3 


44 


2C 


1 

1... 

.XXX xxxx 


45 


2D 


3 


48 


30 


4 


52 


34 


4 



TCBWFC 

TCBFRO 

TCBSYS 
TCBSTP 
TCBFCDl 
PNDSP 

TCBLMP 
TCBDSP 

TCBLLS 
TCBJLB 



TCBJPQ 

TCBGRSO 

TCBGRSl 



Indicates to the I/O Supervisor that there are no 
more request queue elements. 

Indicates that this task is nondispatchable due 
to SMF time limit expiration. User exit routine 
is attempting to extend time limit. 
Reserved as status bits to indicate 
nondi s pat cha bi 1 it y . 

Indicates that this task is nondispatchable 
because VARY or QUIESCE processing is being done 
in a multiprocessing system. 

Indicates that the current task is nondispatch- 
able while the dump data set is being opened for 
another task in the same job step. 



Indicates that this task has terminated, normally 
or abnormally, and is nondispatchable. 
Indicates that this task is nondispatchable 
because it is to be terminated by the ABEND 
routine. 

"Wait for Core" nondispatchability flag. If set, 
indicates that this task is waiting for a space 
request to be satisfied by the rollout mechanism. 
Meaningful in all TCBs except those for permanent 
system tasks - 

"Rolled Out" nondispatchability flag. If set, 
indicates that this task is nondispatchable 
because it has been rolled out. This flag is set 
in all TCBs of a rolled-out job step, including 
the TCB of the associated initiator. 
Indicates that this task is nondispatchable 
because another task is in "system must complete" 
status . 

Indicates that this task is nondispatchable 
because another task in the same job step is in 
"step must complete" status. 
Indicates that this task is nondispatchable 
because it is an initiator task that is waiting 
for a requested region of main storage. 
Indicates that this task has been set nondis- 
patchable. See bytes 173, 174, and 175 for the 
specific reason. 

Limit priority. 

Dispatching priority. 

Zero. 

Address of last load list element in the load 
list. 

Zero. 

Address of job library DCB. 

JPQ purge flag. 

Purge flag. 
Zero. 

Address of last CDE for job pack area. 

Save area for general register 0. 

Save area for general register 1. 
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56 


38 


4 


60 


3C 


4 


6H 


40 


4 


68 


44 


4 


72 


48 


4 


76 


4C 


4 


80 


50 


4 


an 


54 


4 


88 


58 


4 


92 


5C 


4 


96 


60 


4 


100 


64 


4 


loa 


68 


4 


108 


6C 


4 


112 


70 


1 


113 


71 


3 


116 


74 


1 


117 


75 


3 


120 


78 


1 


121 


79 


3 


124 


7C 


1 


125 


7D 


3 


128 


80 


1 


129 


81 


3 


132 


84 


1 


133 


85 


3 


136 


88 


1 


137 


89 


3 


140 


8C 


1 


141 


8D 


3 



144 90 



TCBGRS2 Save area for general register 2. 

TCBGRS3 Save area for general register 3. 

TCBGRS4 Save area for general register 4. 

TCBGRS5 Save area for general register 5 . 

TCBGRS6 Save area for general register 6. 

TCBGRS7 Save area for general register 7. 

TCBGRS8 Save area for general register 8. 

TCBGRS9 Save area for general register 9 . 

TCBGRSIO Save area for general register 10. 

TCBGRSll Save area for general register 11. 

TCBGRS12 Save area for general register 12. 

TCBGRS13 Save area for general register 13. 

TCBGRS14 Save area for general register 14. 

TCBGRS15 Save area for general register 15. 

TCBQEL Enqueue count. 

TCBFSA Address of first problem program save area for 
this task. 

Zero. 

TCBTCB Address of next TCB on TCB queue. (In rollout 
TCB, contains address of first transient area 
TCB. ) 

Zero. 
TCBTME Address of timer queue element for this task. 

Zero. 
TCBJSTCB Address of the job-step TCB. 

Zero. 

TCBNTC Address of next TCB attached by originating task. 
(Always in rollout TCB . ) 

Zero. 

TCBOTC Address of originating or parent TCB. 

Zero. 

TCBLTC Address of last TCB on subtask queue. (Alvrays 
in rollout TCB.) 

Zero. 

TCBIQE Address of the IQE for scheduling an end-of-task 
Exit routine. 

Zero. 
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145 91 3 

1U8 94 1 
1. 







**«x ••«• 






.... xxxx 


149 


95 


1 


150 


96 


1 


151 


97 


1 


152 


98 


1 


153 


99 


3 


156 


9C 


1 


157 


9D 


3 



TCBECB 



TCBTSFLG 

TCBTSTSK 
TCBSTPPR 



TCBATT 
TCBTIOTG 

TCBSTPCT 

TCBSLP 
TCBTSDP 

TCBPQE 
TCBAQE 



160 AO 1 






...1 



161 


Al 


3 






TCBNSTAE 


164 


A4 


1 








165 


A5 


3 






TCBTCT 


168 


A8 


4 






TCBUSER 


172 


AC 


1 






TCBDAR 






1.. 


• 


• • • • 


TCBDARP 






.1. 


• 


• • • a 


TCBDARS 






• • « 


1 


• ■ a • 


TCBDARMC 






• • « 


• 


1... 


TCBDAROL 



Address of ECB to be posted when this task is 
complete. 

Time sharing flags. 

Indicates a time sharing task. 

Indicates that this task should be made nondis- 
patchable when it is no longer executing a privi- 
leged program. 

Indicates that a system routine is executing and 
requires that this task not be interrupted by an 
attention exit or by the STATUS SVC routine. 
Indicates that TGET/TPUT should be purged due to 
an attention. 
Resein^ed. 

Number of STATUS starts vrtiich must be issued 
before the task becomes dispatchable. 

Limit priority of time sharing task. 

Dispatching priority of time sharing task. 

Zero. 

Address of dummy PQE-8 (first element on PQE list 
for job step) . 

Zero. 

List origin of allocated queue elements for this 
task. 

STAE flags. 

ASIR routines were entered. 

STAE routine invoked the Purge I/O routine with 

the quiesce I/O option. 

current SCB has the XCTL=YES option. 

SCB was created by a program that is scatter 

loaded. 

Purge I/O routine did not successfully quiesce 

I/O, but I/O was halted. 

Program using STAE is in supervisor mode. 

STAE user requested that a retry routine be 

scheduled but that the RB chain not be purged. 

Retry routine and parameter list addresses are 

both valid. This bit also set by RNS to indicate 

that Storage Reconfiguration is necessary because 

of a solid machine failure. 

Address of STAE control block (SCB) . 

Zero. 

Address of timing control table (SMF only) . 

Field to be used by users. 

Flags . 

Primary (valid) DAR recursion. (Always set for 

current task in a DAR dump.) 

Secondary (invalid) DAR recursion. (Set prior to 

task reinstatement.) 

DAR has been entered to handle a valid recursion 

in "must complete" status through ABEND. 

Reserved. 
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• • • • 


.1.. 


TCBDARWT 




• • • « 


...1 


TCBEXSVC 




. .X. 


. .X. 




173 AD 


3 




TCBNDSP 




Byte 





TCBNDSPl 




1... 


« • • • 


TNONDISP 




.1.. 


• • • • 


PNONDISP 




-.1. 


• • • • 






...1 


• • • • 






• • • • 


1... 


TCBDDRND 




• • • • 


.XXX 






Byte 


1 


TCBNDSP2 




Byte 


2 


TCBNDSP3 


176 BO 


4 






180 BH 


1 




TCBRECDE 




Ixxx 


xxxx 


TCBREC 




xOOO 


0001 


TCBOPEN 




xOOO 


0010 


TCBCLOSD 




xOOO 


0011 


TCBCLOSE 




xOOO 


0100 


TCBCLOSF 




xOOO 


0101 


TCBGREC 




xOOO 


0110 






xOOO 


0111 


TCBADUMP 




xOOO 


1000 


TCBPTAXE 




xOOO 


1001 


TCBMESG 




xOOO 


1010 


TCBDYNAM 




xOOO 


1011 






xOOO 


1100 


TCBQTIP 




xOOO 


1101 


TCBTCAMP 




xOOO 


1110 


TCBTCAMR 




xOOO 


1111 


TCBSAVCD 




xOOl 


0000 


TCBTYPIW 




xOOl 


0001 ] 






xOlO 


1111 ) 






0011 


0000 


TCBNOSTA 




0011 


0001 


TCBSTRET 




0011 


0010 


TCBCONVR 




0011 


0011 


TCBDARET 




0011 


0100 


TCBTYPIR 



WTO in process for "Reinstatement Failure* 

message. 

SVC dump is executing for this task. 

Reserved. 

Flags . 

Flags . 

DAR has set the task temporarily nondispatchable. 

DAR has set the task permanently nondispatchable. 

RMS or SER has set the task temporarily 

nondi s pat cha bl e . 

RMS or SER has set the task permanently 

nondi s pat cha bl e . 

DDR has set the task (under which allocation is 

running) temporarily nondispatchable. 

Reserved. 

Rese3n^ed. 

Reserved. 

Reserved. 

Flags. 

Recursion Configuration Flags: 

Valid recursion flag. 

OPEN macro instruction has been issued by ABEND 
for the dump data set for this task. 
CLOSE macro instruction has been issued by ABEND 
for the direct SYSOUT data set on tape for the 
job step. 

CLOSE macro instruction has been issued by ABEND 
for an open data set for this task. 
Force Close routine has been given control by 
ABEND for graphics jobs. 

Graphics Debug routine has been given control by 
ABEND. 
Reserved. 

ABDOMP is in progress for this task. 
Purge TAXE routine in EOT given control for cur- 
rent task. 
Reserved. 

Data management module to check TIOT for dynamic 
DD entries invalidly marked busy has been given 
control . 
Reserved. 

ABEND is purging TSO Inter-Partition POST 
requests . 

ABEND is purging TCAM POST requests. 
TCAM Message Control Program (MCP) Reinitializa- 
tion routine has been given control. 
Save old TCB completion code. (ABEND during ASIR 
processing.) 

Invalid ABEND recursion from type-1 SVC WTP 
message. 



Reserved for recursions. 



Communication Configuration Flags: 
STAE/STAI not to be honored. 
Return from "steal core" routine. 
Convert to job step ABEND. 
Return from DAR. 
Reserved. 
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0011 0101 
0011 Olio 



0011 1111 
0100 0000 



TCBNEWRB 



0111 1111 
181 B5 3 



ABEND initiated SVC 13 to XCTL to non-ABEND 
routine. 



Reserved for communications. 



Reserved. 



TCBJSCB Address of job-step control block. 
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Positions of Permanent System TCBs on TCB Queue 

















^ 


lEATCBl 


Transient Area TCB, 


CVTHEAD 


lEAHEAD 


■^ 


















IEATCB2 






Communications 




Transient Area TCBo 


Vecfor Table 


T 






lEATCBn 


Transient Area TCB 
n 




'' 






lEAERTCB 


System Error TCB 






\ 






lEAROTCB 


Rollout/RollInTCB 






r 




Note: The TCBs are queued 
in dsscendlng order 
of dispatching priority 


lEECVTCB 


Communications TCB 




' 








IGFRMTCB 


Dynamic Device 
Reconfiguration TCB 




' 












Master Scheduler TCB 
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SOPERVISOR REQUEST BLOCK (SVRB) — FOR RESIDENT ROUTINE 



Offset 
Dec Hex 




4 

8 

9 

10 



12 



13 




4 

8 
9 

A 



Bits and 
Byte Pattern 

4 

4 

1 

1 
2 
Byte 

X A • • • « • • 



• • X ■ ■ XXX 

Byte 1 



XX. . 

..1. 



1 


RBCDFLGS 


xxxx • • * « 




•••• X*** 


WAE 


•••• aXa* 


RBCDSYNC 


• ••• vaXa 


RBCDXCTL 


1 


RBCDLD 



16 


10 


8 


24 


18 


1 


25 


19 


3 


28 


IC 


1 


29 


ID 


3 


32 


20 


64 



96 



60 



48 



Field 

Name Field Description. Contents. Meaning 

Reserved. 

RBABOPSW Bits 32-63 of user's PSW at time system detected 
abnormal termination condition. 

RBWCSA Wait coTint save area. 

RBSIZE Size, in doublewords, of RB. 

RBSTAB Status and attribute bits. 



RBFTP RB type: 00 = PRB. 

01 = IRB. 

10 = SIRB. 

11 = SVRB. 

RBFNSVRB SVRB for a transient SVC routine. 
RBWAITP RB waiting on one or more BCBs. 
Reserved. 



RBTCBNXT RELINK field points to a TCB. 

RBFACTV IRB or SIRB queued to a TCB. 

RBATTN Meaningful only for an IRB. 

RBDSIQE ATTACH created IRB for a user asynchronous exit 

routine. IQE must be freed by asynchronous exit 

routine. 
RBIQETP Meaningful only for an IRB or SIRB. 
RBFDYN RB space can be freed at exit. 
RBECBWT = wait for single event or n of n events. 

1 = wait for m of n events (where m is less than 
n). 

Contents control flags. 

Reserved. 

Work area exists. 

SYNCH macro instruction issued. 

XCTL macro instruction issued. 

LOAD macro instruction issued. 

RBCDE Address of CDE used by Link routine when forming 
a PRB. 

RBOPSW RB old PSW. 

Zero. 

RBPGMQ Queue field for serially reusable programs. 

RBWCF Wait count. 

RBLINK Address of next RB on RB queue. 

RBGRSAVE General register save area, in the sequence 
through 15. 

RBEXSAVE Extended save area for SVC routines. 
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SUPERVISOR REQUEST BLOCK (SVRB) — FOR NONRESIDEMT ROUTINE 



Offset 
Dec Hex 


Bits 
Byte 


and 
Pattern 


Field 
Name 








2 




RBTABNO 


2 


2 


2 




RBRTLNTH 


H 


4 


4 




RBABOPSW 


8 


8 


1 




RBWCSA 


9 


9 


1 




RBSIZE 


10 


A 


2 




RBSTAB 






Byte 

XX.. 





RBFTP 






...1 

• • • •- 


• • • « 

1... 


RBFNSVRB 
RBWAITP 






• • X* 


.XXX 








Byte 
1... 
.1.. 
.-1. 
...1 


1 

« • • • 
« « « • 
« « • • 
• « ■ ■ 


RBTCBNXT 
RBFACTV 
RBATTN 
RBUSIQE 






« • • •- 

• • • • 

* • • «. 


XX. . 

..1. 

• • • X 


RBIQETP 

RBFDYN 

RBECBWT 


12 


C 


4 




RBSVTON 


16 


10 


8 




RBOPSW 


2H 


18 


1 




RBTAWCSA 


25 


19 


3 




RBSVTTR 


28 


IC 


1 




RBWCF 


29 


ID 


3 




RBLINK 


32 


20 


64 




RBGRSAVE 



96 



60 



48 



RBEXSAVE 



Field Description, Contents, Meaning 

Displacement of TACT entry. 

Length, in bytes, of SVC routine. 

Bits 32-63 of user's PSW at time system detected 
abnormal termination condition. 

Wait count save area. 

Size, in doublewords, of RB. 

Status and attribute bits. 



RB type: 00 = PRB. 
01 = IRB. 

10 = SIRB. 

11 = SVRB. 

SVRB for a transient SVC routine. 
RB waiting on one or more ECBs. 
Reserved. 



RBLINK field points to a TCB. 

IRB or SIRB queued to a TCB. 

Meaningful only for an IRB. 

ATTACH created the IRB for a user asynchronous 

exit routine. IQE must be freed by asynchronous 

exit routine. 

Meaningful only for an IRB or SIRB. 

RB space can be freed at exit. 

= wait for single event or for n or n events. 

1 = wait for m of n events (where m is less than 

n). 

Address of next RB on transient area queue. 

RB old PSW. 

Wait count save area for transient area handling. 

TTR for SVC routine. 

Wait count . 

Address of next RB on RB queue for task. 

General register save area, in the sequence 
through 15. 

Extended save area for SVC routines. 
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INTERRUPTION REQUEST BLOCK (IRB) 



Offset 


Bits 


and 


Field 


Dec Hex 


Byte 


Pattern 


Name 





1 




RBTMFLD 




1... 


• • • « 


RBTMQUE 




.1.. 


• « • • 


RBTMTOD 




..XX 


* • • • 


RBTMINDl 




• • • • 


1... 


RBTMCMP 




• • • • 


.1.. 


RBTMIND2 




• •- • • 


. .XX 


RBTMIND3 



1 


1 


3 




4 


4 


4 




8 


8 


1 




9 


9 


1 




10 


A 


2 








Byte 









XX.. 


• • • • 






...1 

« • • • 


• • • • 

1... 






. .X. 


.XXX 






Byte 


1 






1... 


• • • • 






.1.. 
. .1. 


• • • • 






...1 


• • • • 






RBPPSAV 
RBABOPSW 

RBWCSA 
RBSIZE 
RBSTAB 

RBFTP 



RBFNSVRB 
RBWAITP 



RBTCBNXT 
RBFACTV 
RBATTN 
RBUSIQE 



RBIQETP 



Field Description. Contents^ Meaning 

Timer routine flags. 

Timer element not on queue. 

Local TOD option used. 

00 = TUINTVL requested. 

01 = BINTVL requested. 

10 = reserved. 

11 = DECINTVL requested. 
Interval is complete. 

Midnight supervisory timer element. 

00 = task request. 

01 = wait request. 

10 = supervisory element. 

11 = RBAL request. 

Address of problem program register save area. 

Bits 32-63 of user's PSW at the time system 
detected abnormal termination condition. 

Wait count save area. 

Size, in doublewords, of RB. 

Status and attribute bits. 



RB type: 00 = PRB. 
01 = IRB. 

10 = SIRB. 

11 = SVRB. 

SVRB for a transient SVC routine. 
RB waiting on one or more ECBs. 
Reserved. 



RBLINK field points to a TCB. 
IRB or SIRB queued to a TCB. 
Exiting program is an attention exit. 
ATTACH created the IRB for a user asynchronous 
exit routine. The IQE must be freed by the asyn- 
chronous exit routine. 
Asynchronous exit queue element type. 

00 = RQE not to be queued to "next available" 

list (lECNXAVL) by the Exit routine. (Since 
the RB is an SIRB, the RQE has already been 
queued by the error exit routine.) 

01 = IRB has asynchronous exit queue elements 

that are RQEs. 

10* = IQE not to be queued to "next available" 

list (RBNEXAV) by the Exit routine. (These 
bit settings are used with the rollout 
IRB.) 

11* = IRB has asynchronous exit queue elements 
that are IQEs. IQE is to be queued to 
"next available" list by the Exit routine. 



♦The RETIQE operand of the CIRB macro instruction 
determines these settings. If RETIQE = YES, *11' 
is set. If RETIQE = NO, "10' is set. (If the 
operand is not specified, '11' is set.) 



Section 12: Control Blocks and Tables 293 



12 C 
16 10 

24 18 



25 



19 



4 
8 



24 


18 


2 


26 


lA 


2 


28 


IC 


1 


29 


ID 


3 


32 


20 


64 


96 


60 


4 



..1. 



100 64 



Variable 



Note ; If rollout is included during system 
generation, NIP issues the CIRB macro instruction 
to create and initialize the rollout IRB. 

RBFDYN RB space can be freed at exit. 

RBECBWT = wait for single event or for n of n events. 
1 = wait for m of n events (where m is less than 
n). 

RBEP Entry- point address. 

RBOPSW Old PSW. 

THREE- BYTE LINK-FIELD SEGMENT 
RBUSE Attach use count. Used only when the IRB sche- 
dules an end-of-task exit (ETXR) routine. 

RBIQE List origin for IQEs. 

TWO-BYTE LINK-FIELD SEGMENT 
Reserved. 

RBIQE List origin for RQEs. 

RBWCF Wait count. 

RELINK Address of next RB or RB queue. 

RBGRSAVE General register save area, in the sequence 0-15. 

RBNEXAV Address of next available IQE. The RBNEXAV field 
and the IQE work space are available only in IRBs 
for which this work space was requested via a 
CIRB macro instruction. 

IQE work space. 
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SYSTEM INTERRUPTION REQUEST BLOCK (SIRS) 



Offset 
pec Hex 



Bits and 
Byte Pattern 

8 



Field 
Name 

RBEXRTNM 



8 


8 


1 




9 


9 


1 




10 


A 


2 








Byte 









XX.. 


• ■ • • 






...1 


• • • • 






• • • • 


1... 






. .X. 


.XXX 






Byte 


1 






1... 


• • • • 






.1.. 


• • • • 






..1. 


« • « • 






...1 


• • • • 






RBWCSA 
RBSIZE 
RBSTAB 

RBPTP 



RBFNSVRB 
RBWAITP 



RBTCBNXT 
RBFACTV 
RBATTN 
RBUSIQE 



RBIQETP 



..1. 



12 C 4 
16 10 8 
24 18 2 



RBFDYN 
RBECBWT 



RBEP 
RBOPSW 



Field Description, Contents, Meaning 

1-8 character name of error exit routine. First 
4 characters are IGEO. Last 4 are unpacked 
decimal characters, or RBABOPSW (bits 32-63 of 
user's PSW at time system detected abnormal ter- 
mination condition) . 

Wait count save area. 

Size, in doublewords, of RB. 

Status and attribute bits. 



RB type: 00 = PRB. 
01 = IRB. 

10 = SIRB. 

11 = SVRB. 

SVRB for a transient SVC routine. 
RB waiting on one or more ECBs. 
Reserved. 



RBLINK field points to a TCB. 

IRB or SIRB queued to a TCB. 

Meaningful only for an IRB. 

ATTACH created IRB for a user asynchronous exit 

routine. IQE must be freed by asynchronous exit 

routine. 

Asynchronous exit queue element type. 

00 = RQE not to be queued to "next available" 

list (lECNXAVL) by the Exit routine. (Since 
the RB is an SIRB, the RQE has already been 
queued by the error exit routine.) 

01 = IRB has asynchronous exit queue elements 

that are RQEs. 

10* = IQE not to be queued to "next available" 

list (RBNEXAV) by the Exit routine. (These 
bit settings are used with the rollout 
IRB.) 

11* = IRB has asynchronous exit queue elements 
that are IQEs. IQE to be queued to "next 
available" list by Exit routine. 

♦The RETIQE operand of the CIRB macro instruction 
determines these settings. If RETIQE = YES, '11' 
is set. If RETIQE = NO, "lO" is set. (If the 
operand is not specified, '11' is set.) 

Note: If rollout is included during system 
generation, NIP issues the CIRB macro instruction 
to create and initialize the rollout IRB. 

RB space can be freed at exit. 

= wait for single event or for n of n events. 

1 = wait for m of n events (where m is less than 

n). 

Entry-point address. 
RB old PSW. 
Reserved. 
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26 


lA 


2 


28 


IC 


1 


29 


ID 


3 


32 


20 


64 



RBIQE List origin for RQEs. 

RBWCF Wait coiint. 

RELINK Address of next RB on RB queue. 

RBGRSAVE General register save area, in the sequence 
through 15. 



PROGRAM REQDEST BLOCK (PRB) 



Offset 
Dec Hex 




4 

8 

9 

10 



12 




4 

8 
9 
A 



Bits and 
Byte Pattern 

4 

4 

1 
1 
2 
Byte 



Byte 1 



• « • • jCX • • 



Field 
Name 



RBABOPSW 

RBWCSA 
RBSIZE 
RBSTAB 

RBFTP 



RBFNSVRB 
RBWAITP 



RBTCBNXT 
RBFACTV 
RBATTN 
RBUSIQE 



RBIQETP 

RBFDYN 

RBECBWT 



RBCDFLGS 







xxxx 


• • • • 








• • • • 


1... 


WAE 






• • • •. 


.1.. 


RBCDSYNC 






« • • • 


..1. 


RBCDXCTL 






• • • • 


...1 


RBCDLD 


13 


D 


3 




RBCDE 


16 


10 


8 




RBOPSW 


24 


18 


1 






25 


19 


3 




RBPGMQ 


28 


IC 


1 




RBWCF 


29 


ID 


3 




RELINK 



Field Description, Contents, Meaning 

Reserved. 

Bits 32-63 of user's PSW at time system detected 
abnormal termination condition. 

Wait count save area. 

Size, in doublewords, of RB. 

Status and attribute bits. 



RB type: 00 = PRB. 
01 = IRB. 

10 = SIRB. 

11 = SVRB. 

SVRB for a transient SVC routine. 
RB waiting on one or more ECBs. 
Reserved. 



RELINK field points to a TCB. 
IRB or SIRB is queued to a TCE. 
Meaningful only for IRB. 

ATTACH created the IRB for a user asynchronous 
exit routine. IQE must be freed by the asynch- 
ronous exit routine. 
Meaningful only with an IRB or SIRB. 
RE space can be freed at exit. 

= wait for single event or for n of n events. 

1 = wait for m of n events (where m is less than 

n). 

Contents control flags. 

Reserved. 

Work area exists. 

SYNCH macro instruction issued. 

XCTL macro instruction issued. 

LOAD macro instruction issued. 

Address of contents directory entry. 

Old PSW. 

Zero. 

Queue field for serially reusable programs. 

Wait count. 

Address of next RE on RB queue. 
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TRACE TABLE (UNIPROCESSING SYSTEMS) 



Words 



NOTE: Each entry is eighf words 

SIO Instruction; 

1 2 



(See Below) 


Ciiannel 
Address 
Word 


Channel Status Word 


Reserved 





TCB 

found in RQE 


Timer 
Contents 



First Word of SIO Entry: 






2 


3 




13 




21 




31 




/ 









Device 
Address 



-SIO Condition Code 



[/O Inlerruption: 






1 


2 




3 




4 




5 




6 




7 




Bit 13 = 1 
Bits 16-19 = 
0101 






Channe 


Status 
1 


Word 


Reserved 





Reserved 


Timer 
Contents 



I/O Old PSW 
SVC Interruption: 






1 


2 




3 




4 




5 




6 




7 




Bit 13 = 1 
Bits 16-19 = 
0010 




Reg. 15 


Reg. 


Reg. 1 


C 


TCB 


Timer 
Contents 



Program Interruption: 






1 


2 






3 




4 




5 




6 




7 




Bit 13 = 1 
Bits 16-19 = 
0011 






Reg. 


15 


Reg. 


Reg. 1 





TCB 


Timer 
Content3 



Program OPSW 



External Interruption; 
Q. 1 



Bit 13 = 1 
Bits 16-19 = 
0001 




Reg. 15 


Reg. 


Reg. 1 





TQE if Timer 
Interruption 
Otherwise^ Zero 


Timer 
Contents 



External Old PSW 



Dispatcher: 



Bit 13 = 1 
Bits 16-9 = 
1101 




Reg. 15 


Reg. 


Reg. 1 





New 
TCB 


Timer 
Contents 



The addresses of the trace table are contained In a 12- byte field whose address Is at 
hex loc 54. The format of the field is: 



Bytes 



3 4 



Address of Lost Entry 


Address of Table Beginning 


Address of Table End 
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TRACE TABLE (MULTIPROCESSING SYSTEMS) 



TRACE TABLE (Mulliprocessing Systems) 
NOTE: Each enfry is eight words 
SIO instruction: 

Words 






1 


2 


3 


4 




5 




5 


7 




























C 


{See Below) 


Channel 
Address 
Word 




Channel Status Word 




TCB 




'Old' TCB 
of CPUA 


'Old' TCB 
of CPUB 




Timer 
Contents 


P 

U 
1 
D 



First Word of SIO Entry: 

2 3 13 21 





\ 









Device 
Address 



-SIO Condition Code 



I/O Interruptic 






1 


2 


3 




4 




5 


6 


7 




























C 


Bit 13= 1 
Bits 16 - 19 = 
0101 




Reg 15 




RegO 




Reg 1 


'Old' TCB 
of CPUA 


'Old' TCB 
of CPUB 




Timer 
Contents 


P 
U 
1 
D 



I/O Old PSW 



SVC Interruption: 






1 


2 




3 




4 




5 




6 


7 






Bit 13 = 1 
Bits 16-19 = 
0010 




Reg 15 


Reg 


Reg 1 


'Old' TCB 
of CPUA 


'Old' TCB 
of CPUB 


Timer 
Contents 


C 

P 
U 
1 
D 



Program Interruption: 
Words 






1 


2 




3 




4 




5 


6 


7 






























C 


Bit 13= 1 
Bits 16-19 = 
0011 






Reg 15 




Reg 




Reg 1 


'Old' TCB 
of CPUA 


'Old' TCB 
of CPUB 




Timer 
Contents 


P 

u 
1 

D 



Program Old PSW 



SSM Program Interruption (Multisystem Mode 
Words 






1 


2 


3 




4 




5 




6 


7 






























C 


Bit 13= I 
Bits 16-19 = 
0100 




Reg 15 




RegO 




Reg 1 


\ 


'Old' TCB 
of CPUA 


'Old' TCB 
of CPUB 




Timer 
Contents 


P 
U 

1 
D 



Program Old PSW 



-CPUID of locking CPU 



External Interruption: 
Words 1 



Bit 13= 1 
Bits 16-19 = 
0001 




Reg 15 


RegO 


Reg 1 


STMASK 
of other 
CPU 


TQE if timer 
interruption 
otherwise, 
zero 


Timer 
Contents 


C 
P 
U 
1 
D 



Externol Old PSW 



Dispatcher: 
Words 1 



Bit 13= 1 
Bits 16-19 = 

noi 




Reg 15 


Reg 


Reg 1 


'New' TCB 
of CPUA 


'New' TCB 
of CPUB 


Timer 
Contents 


C 

P 
U 
1 
D 



Bytes 



The addresses of the trace toble ore contoined in a 12-b)'te field whose 
address is at hex loc 54. The- rornot of the field is: 










34 




7 8 






Address of Los 


Entry 




Address of Table Beginning 


Address of Table End 
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TRANSIENT AREA CONTROL TABLE (TACT) 

The TACT (entry point lEAQTAQ) consists of a four^word entry for each transient area 
block (TAB) in the system. The first entry is preceeded by a twcword prefix. Each 
entjry has the format described below: 



Field Description. Contents, Meaning 
Request queue pointer. 
Number of TACT entries. 

Flags . 

TAB is being loaded. 

TAB is free (unoccupied) . 

TAB is being used. 

Address of associated TCB. 

SVRB chain of users overlayed by a higher priori- 
ty task. 

SVRB chain of requestors who could not find a 
usable TAB. 

Track address in SVC library of the routine cur- 
rently in the TAB. This address used to identify 
routine. 

Count of recycles of BLDL and FETCH operations 
after report of permanent I/O error by BLDL and 
FETCH - area used by Transient Area Fetch. 

Address of transient area fetch TCB under whose 
control routines are fetched to the TAB. 



Offset 
Dec Hex 


Bits 
Byte 


and 
Pattern 


Field 
Name 


-8 -8 


4 






-4 -4 


4 






Entry 1 











1 








.1.. 
..1. 
0000 


• • • • 

• • • a 

0000 




1 1 


3 






4 4 


4 







12 



13 



Entry 2 begins at location 16(10). 
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PROGRAM INTERRUPTION ELEMENT (PIE) 



Offset 
Dec Hex 



Bits and 
Byte Pattern 

1 



Field 
Name 







. XXX xxxx 




1 


1 


3 


PIEPICA 


n 


4 


8 


PIEPSW 


12 


C 


4 


PIEGR14 


16 


10 


4 


PIEGR15 


20 


14 


4 


PIEGRO 


24 


18 


4 


PIEGRl 


28 


IC 


4 


PIEGR2 



Field Description, Contents. Meaning 

The PIE must begin on a doubleword boundary. 

First-time logic switch. If set to one, indi- 
cates that the task cannot accept further program 
interruptions. (This bit is set ^enever a user 
PI exit routine is entered. It is reset by the 
SVC Exit routine.) 
Reserved. 

Address of current PICA. 

Program interruption old PSW stored at time of 
program interruption. 

Save area for register 14. 

Save area for register 15. 

Save area for register . 

Save area for register 1. 

Save area for register 2. 



PROGRAM INTERRUPTION CONTROI. AREA (PICA) 



Offset 
Dec Hex 


Bits and 
Byte Pattern 

1 

xxxx .... 
.... xxxx 


Field 

Name J 





1 

PICAPRMK 



PICAEXIT 



Byte 0, bit 
Remaining 
bits 



PICAITMK 



Field Description, Contents, Meaning 

The PICA must begin on a fullword boundary. 

Zero. 

Program mask to be used in the PSW when the pro- 
grams of the task are executing. 

Address of the user's program interruption exit 
routine to be given control when a program inter- 
ruption of specified type occurs. 

Program interruption types. 

Reserved. 

Mask that indicates on which program interruption 
types the exit routine is to be used. The bits 
are numbered 1 through 15, left to right. A bit 
set to one indicates user interest in that type. 
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STAE CONTROL BLOCK (SCB) 



Offset Bits and Field 
Dec Hex Byte Pattern Name 



8 8 1 






9 9 3 
12 C 1 



• • • 3uuC ■ 
« • • • • ■ X 



13 D 3 



Field Description. Contents. Meaning 

TCB STAE flag byte for the previous SCB for this 
task, or zero if this is the first SCB for this 
task. 

Address of previous SCB for this task, or zero if 
this is the first SCB created for this task. 

Address of user-written STAE exit routine as spe- 
cified in STAE macro instruction. 

Flags. 

Reserved. 

Allow asynchronous interruptions. 

00 = quiesce I/O. 

01 = halt I/O. 

10 = bypass I/O intervention. 

Address of parameter list to be passed to STAE 
exit routine as specified in STAE macro 
instruction. 

STAE flags. 

SCB will not be canceled by Exit routine when 

XCTL is issued. 

ISAM/TAM switch. 

STAI SCB. 

SCB previously used. 

Reserved. 

STAI issuer is in supervisor mode. 

Address of RB of task issuing STAE macro 
instruction. 



STAE PARAMETER LIST 

The STAE parameter list is pointed to by the STAE control block. 



Offset 
Dec Hex 



1 
H 



1 
4 



Bits and 
Byte Pattern 



.XXX X. 



Field 
Name 



Field Description. Contents, Meaning 

Flags. 

STAI parameter list. 

Reserved. 

Allow asynchronous interruptions. 

00 = quiesce I/O. 

01 = halt I/O. 

10 = bypass I/O processing. 

Address of STAE or STAI exit routine. 

Address of STAE exit routine parameter list, or 
zero. 

Address of attached TCB. 
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EVENT CONTROL BLOCK (ECB) 



Offset Bits and Field 
Dec Hex Byte Pattern Name 

Bits 0-1 
W C 



Bits 2-7 
mill 
000001 
000010 

000100 



001000 



001111 



Bits 8-31 



Field Description. Contents. Meaning 

W = bit 0; C = bit 1. 

W = wait flag; C = completion flag. 

Event has not been awaited and has not been post- 
ed complete. Bits 2-31 may contain meaningless 
infojcmation. 

Event has been posted complete, but it has not 
yet been awaited. Bits 2-31 contain the comple- 
tion code in the high-order positions; zeros in 
the low-order positions. 

Event has been awaited, but has not yet been 
posted complete. Bits 2-7 are zero, and bits 
8-31 contain the address of the RB under which 
the WAIT macro instruction was issued. 

Task waiting for an event abnormally terminated 
before the event was posted. ABEND will purge 
the ECB. Bits 0-7 are zero, and bits 8-31 con- 
tain the address of the RB under which the WAIT 
macro instruction was issued. 

Completion code. 

Normal completion (no errors). 

I/O permanent error code. 

Extent permanent error code. Indicates that the 
seek address specified in the lOB is out of the 
extent specified in the DEB. 

lOB intercept code. Whenever an error occurs 
after a channel end interruption for a device, 
the I/O request for that device has already been 
posted complete and the request element returned 
to the freelist. To handle the error, the I/O 
supervisor sets the UCB intercept flag to indic- 
ate that the next I/O request for that device 
must be intercepted. When intercepted, the lOB 
for the new I/O request and the CSW and sense 
data for the error are passed to the error reco- 
very procedures for the device. If a permanent 
error exists, the ECB for the intercepted lOB is 
posted complete with the lOB intercept code. 

Not started or purged. Either the I/O request 
has not been started, or it has been purged. 

Error could not be retried. Home address and/or 
RO could not be read during error recovery 
procedures. 

Address of the RB under which the WAIT macro 
in s tr uction wa s is sued . 



302 



PARAMETER LIST ELEMENT (FOR THE ENQ/DEQ RODTINES) 

Offset Bits and Field 
Dec Hex Byte Pattern Hame Field Description. Contents. Meaning 

1 LISTEND Last element in parameter list. Last element 

must have X'FF' in field; all other elements have 
any other value. 

Ill LMINOR Length of minor name whose address is at offset 

8, or zero. If zero, the length of the minor 
name is assumed to be in the first byte of the 
name field whose address is at offset 8. In this 
case, length byte does not include its own 
length. 

2 2 1 PARMCDS ENQ/DEQ parameters. 

X = exclusive request. 

1 = shared request. 
.X = minor name known only to job step. 

1 = scope of minor name SYSTEM. 

..1 "Set Must Complete" = SYSTEM. 

...1 .... "Set Must Complete" = STEP. 

.... X . . . Reserved . 

XXX 111 : RET = TEST. 

Oil : RET = USE. 

001 : RET = HAVE. 

000 : RET = NONE. 

3 3 1 Return code field for codes returned to the issu- 

er of the ENQ or DEQ macro instruction. 

H H H Address of major resource name (Qname) . 

8 8 4 Address of minor resource name (Rname) . 
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MAJOR QUEUE CONTROL BLOCK (QCB) 



Offset 


Bits and 


Field 


Dec 


Hex 


Byte Pattern 


Name 








H 




4 


4 


H 




8 


8 


H 




12 


C 


4 




16 


10 


4 





Field Description, Contents. Meaning 

Address of next major QCB (if last, equals zero) . 

Address of previous major QCB (if first, equals 
lEAQQCB) . 

Address of first minor QCB on queue of minors. 

Major QCB name (first four characters). 

Major QCB name (last four characters). 



MINOR QUEUE CONTROL BLOCK (QCB) 



Offset 


Bits and 


Dec 


Hex 



Bvte Pattern 





4 


4 


4 


4 


8 


8 


4 


12 


C 


1 


13 


D 


1 



14 



Field 
Name 



QCBPKF 



Variable 



Field Description. Contents, Meaning 

Address of first QEL on QEL queue. 

Address of previous minor QCB (if first, equals 
major QCB) . 

Address of next minor QCB (if last, equals zero). 

Length of QCB name. 

•FF' = name known to entire system. 
•00', '10', '20', '30', or 'FO' = protection key 
of TCB under which request was enqueued. Name 
known only to job step. 

Minor QCB name (ATariable in length from 1-255 
characters ) . 
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QUEUE ELEMENT (QEL) 



Offset 


Bits 


and 


Field 


Dec 


Hex 


Byte 


Pattern 


Name 








1 

0010 
0001 
0000 


0000 
0000 
0000 


SMC 


1 


1 


3 






i» 


4 


1 
X. .. 

.1-. 


• • • • 

• • • • 


CODE 



5 
8 



12 



13 



QELTJIDl 

QELTCB 

QELTJID2 

QELSVRB 



Field Description. Contents. Meaning 

Request status represented by QEL. 

"System must complete" request. 

■Step must complete" request. 

"Must complete" status not requested. 

Address of next QEL (zero if last QEL) . 



= exclusive request. 

1 = shared request. 

If shared DASD is included in system, indicates 
that a UCB address appears at byte 12 of QEL, and 
that QEL is associated with a RESERVE rather than 
an ENQ macro instruction. 



Address of previous QEL on queue, 
address of minor QCB. 



In first QEL, 



First half of TSO user ID when user not in main 
storage (high order bit set to 1 indicates pre- 
sence of TJID) . 

Address of TCB under which ENQ macro instruction 
issued. 

Second half of TSO user ID when user not in main 
storage. 

Address of SVRB under which the ENQ routine is 
operating. In systems with shared DASD, if the 
QEL represents a RESERVE request that has been 
satisfied, this field contains the address of the 
UCB of the direct access device on which the 
requested resource resides. 
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INTERRUPTION QUEUE ELEMENT (IQE) 



Offset 


Bits 


and 


Field 


Dec 


Hex 


Byte 


Pattern 


Name 








1 






1 


1 


3 




IQRT.NK 


4 


4 


U 




IQEPARAM 


8 


8 


1 






9 


9 


3 




IQEIRB 


12 


C 


1 






13 


D 


3 




IQETCB 



Field Description, Contents. Meaning 

Reserved. 

Address of the next IQE on the IQE queue. 

Parameter list to be passed to the asynchronous 
exit routine. 

Reserved. 

Address of the IRB that is to be scheduled 
because of this request. 

Reserved. 

Address of the TCB with vihicb this request is 
associated. 



The following constitutes the optional Rollout/Rollin Parameter List 
16 10 4 RPLTCB 



20 
21 



14 
15 



1 
3 



RPLSZPQE 



Address of the TCB for the task requiring or 
releasing an extension to a region. 

Reserved. 

Size of region requested (rollout request) , or 
address of PQE describing area (rollin request) 
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MESSAGE INFORMR.TI ON LIST (FOR TYPE-1 SVC ROUTINES) 

The Message Information List contains information stored by type-1 SVC routines. Each 
entry consists of seven words; the first entry is preceeded by a one-word prefix. The 
format of each entry is described below; 



Offset 
Dec Hex 

-4 -H 

Entry 1 



Bits and 
Byte Pattern 



Field 
Name 



INFTCB 



INFBADDR 



Field Description. Contents. Meaning 
Address of end of list. 



Address of the TCB for which the information is 
pertinent. 

Return address (branch address) of the calling 
routine from register lU if entry to the type-1 
SVC routine was via a branch instruction. 



INFRCL 



.X xxxx 



Reason code for messages having multiple causes 
(0 = no reason code) . 

Number of bytes of variable data contained in the 
INFVAR field. 



9 


9 


1 

.XXX xxxx 


INFFLG 


10 


A 


2 


INFCC 


12 


C 


16 


INFVAR 



Signifies that the INFBADDR field contains a 

valid branch address. 

Reserved. 

System completion code. 

Information to be provided to the user. Up to 
four words of data may be included. 



Entry 2 begins at location 28 (IC). 
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REQUEST QUEUE ELEMENT (RQE) 



Offset 
Dec Hex 



13 




2 



Bits and 
Byte Pattern 

2 

2 



5 


5 


3 


8 


8 


1 


9 


9 


3 


12 


C 


1 



Field 
Name 

RQELNK 

RQEUCB 



RQEIOB 
RQEPRI 



Field Description. Contents, Meaning 

Pointer to next RQE on RQE queue. 

Pointer to UCB- If the low-order bit is 1, the 
RQE represents a request for a system error rou- 
tine that operates under an SIRB. 

Contains *FF' if RQE is on free list; otherwise, 
contains zero. 

Address of associated lOB. 

First half of TSO user ID (when user not 



(RQETJIDl) in main storage) . 

RQEDEB Address of associated DEB. 



RQETCB 



Protection key of requestor's task or RQETJID2 
(second half of TSO user ID). 

Address of TCB with which I/O request is 
associated. 
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CONTENTS DIRECTORY ELEMENT (CPE) 



Offset 


Bits 


and 


Field 


Dec Hex 


Byte 


Pattern 


Name 





1 




CDATTK 




1... 


• • • • 


NIP 




.1.. 


• • • • 


NIC 




..1. 


• • • • 


REN 




...1 


• • • « 


SER 




• • • • 


1... 


NFN 




• • • • 


.1-- 


MIN 







. .X. 


JPA 







...1 


NLR 


1 1 


3 




CDCHAIN 


u ^ 


1 




CDROLL 


5 5 


3 




CDRBP 



16 



10 



17 


11 


3 


20 


14 


1 

1 



CDNAME 

CDUSE 

CDENTPT 
CDATTR2 
SPZ 



21 15 



.1.. 


• • • ■ 


REL 


..1. 


• • • • 


XLE 


...1 


• • • ■ 


RLC 


• « • ■ 


1... 


REFR 


• • • ■ 


.1.. 


CDOLY 


• • • • 


. .XX 




3 




CDXLMJP 



Field Description. Contents. Meaning 

Attribute field. 

Module was loaded by NIP- 

Module is in process of being loaded. 

Module is reenterable. 

Module is serially reusable. 

Module may not be reused. (Meaningless if REN or 

SER is set.) 

This is a minor CDE. 

= module in subpool 252. 

1 = module in subpool 251. 
Module is not loadable-only. 

Address of next CDE in queue (either the JPACQ or 
the LPACQ) . 

Reserved. 

RB address. If the module is reenterable, this 
field contains the address of the last RB that 
requested the module. If the module is serially 
reusable, this field contains the address of the 
RB at the top of the waiting (RBPGMQ) queue. If 
the module was requested only through LOAD macro 
instructions, contains zero. 

Module name, alias name, or a name that has been 
identified via an IDENTIFY macro instruction. 

Use/responsibility count - the number of out- 
standing requests for the module's use. 

Entry- point address. 

Second attribute field. 

Module is loaded in subpool by the loader, and 

there is no backup copy. The second entry in the 

extent list is the address of a condensed symbol 

table. 

Module is inactive and may be released by the 

GETMAIN routine (CDPURGE) subroutine. 

Extent list has been built for the module. 

CDE contains a minor entry-point address that has 

been relocated by the Program Fetch routine. 

Module is refreshable. 

Module is in overlay form. 

Reserved. 

Extent list address, or major CDE address if this 
CDE is a minor. (If this CDE is a minor, MIN 
field is also set.) 
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LOAD LIST ELEMENT (LLE) 



Offset 
Dec Hex 





1 





1 



Bits and 
Byte Pattern 

1 

3 



Field 
Name 



LLCH2VIN 



LLCOUNT 



Field Description, Contents, Meaning 

Zero. 

Address of first byte of the next element on the 
load list. 

Responsibility count - number of requests for the 
module, via the LOAD macro instruction. 



LLCDPTR Address of the CDE for the module. 



PARTITIONED DATA SET DIRECTORY ENTRY 



Byte 



12 



16 



20 



24 



28 



32 



36 



40 



Name of load module (Member or alias name) 


Relative (to beginning of data set) disk address of module (TTR) 


Alias indicator and 
miscellaneous information 


Relative (to beginning of data set) disk address of first text record (TTR) 


Byte of binary zeroes 
15 


Relative (to beginning of data set) disk address of NOTE list or Scatter/ 
translation record (TTR) 


Number of entries in 
19 NOTE List * 


Module Attributes (see description of attributes) 0, 1 , 
2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, R,R 


Total contiguous main storage required for the 
22-24 ™='"'^- 




Length (in bytes) of first text record 
25 


Module's linkage 
27 


Editor assigned entry point address 


Linkage editor assigned origin of fir^t text record 
30-32 











44 



52 



For load modules in scatter format, odd: 





Length of scatter list ( in bytes ) 
33 


Length of translation table 
35-36 ('" ''y'") 




ESDID (CESD entry number of control section 
name) for first text record 
37 


ESDID (CESD entry number of 
control section name) cont- 
aining entry point 
39-40 




41 





For load modules with RENT or REUS atfrlbufe and 
Alias names odd: 



Entry point address of the member name 



Member name 



SSI Bytes - Aligned on a half-word boundary at the end of the PDS record 
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Offset 


Bits and 


Dec Hex 


Byte Pattern 





8 


8 8 


3 


11 B 


1 




X*«a •••• 



Field 
Name 



.XX. 



■x xxxx 



12 


C 


3 


15 


F 


1 


16 


10 


3 


19 


13 


1 


20 


It 


2 

Byte 
X. .. . 

.X.. . 

. .X. . 



.X . 
.. X 






Byte 1 



Field Description, Contents, Meaning 

Load module name. 

Relative disk address of module (TTR) . 

Alias indicator and miscellaneous information. 

= no alias indicator. 

1 = alias indicator. 

Number of relative disk addresses in user data 

field. 

Length of user data field in half words. 

Relative disk address of first text record (TTR) , 

Byte of binary zeros. 

Relative disk address of NOTE list or scatter/ 
translation record (TTR) . 

Number of entries in NOTE list. 

Module attributes. 



RENT: 



REUS: 



OVLY: 



TEST: 



LOAD: 



= 

1 = 

= 

1 = 

= 

1 = 

= 

1 = 

= 

1 = 



Format : 

1 

Executable 

Format : 

1 



not reenterable. 

reenterable. 

not reusable. 

reusable. 

not an overlay module. 

overlay module. 

not under test. 

under test. 

not loadable-only. 

loadable-only. (Module can be loaded 

only with the LOAD macro instruction. 

When the module is in main storage, it 

will be entered directly, and not 

through the use of an XCTL, LINK, or 

ATTACH macro instruction. ) 

= block format. 

= scatter format. 

= not executable. 

1 = executable. 

= module contains more than one text 
record and/ or RLD record (s). 

= module contains only one text record 
and no RLD record. 



Compatability: = module can be processed by 

all levels of linkage editor. 
1 = module cannot be reprocessed 
by Linkage Editor-E. 
Format: = linkage editor assigned origin of 
first text record is not zero. 
1 = linkage editor assigned origin of 
first text record is zero. 
Format: = linkage editor assigned entry point 
is not zero. 
1 = linkage editor assigned entry point 
is zero. 
Format: = module contains RLD record (s). 
1 = module does not contain an RLD 
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record. 
.... X... Editability: = module can be reprocessed by 

linkage editor. 
1 = module cannot be reprocessed by 
linkage editor. 
X.. Format: = module does not contain TESTRAN sym- 
bol records . 
1 = module contains TESTRAN symbol 
records . 

X. Reserved. 

X Refreshability: = module is not refreshable. 

1 = module is refreshable. 

22 16 3 Total contiguous main storage required for the 

module. 

25 19 2 Length (in bytes) of first text record. 

27 IB 3 Module's linkage editor assigned entry- point 

address. 

30 IE 3 Linkage editor assigned origin of first text 

record . 

For load modules in scatter format, add: 

Length (in bytes) of scatter list. 

Length (in bytes) of translation table. 

ESDID for first text record. 

ESDID containing entry point. 

For load modules with RENT or REUS attribute and alias name, add: 

41 29 3 Entry-point address of member name. 

Hk 2C 8 Member name. 

52 34 4 SSI bytes - aligned on a halfword boundary at the 

end of the PDS record. 

The following list contains PDS directory record sizes. 

Block format 34 bytes (when rounded to a halfword boundary) . 

Block format with alias name 44 bytes. 

Scatter format 42 bytes. 

Scatter format with alias name 52 bytes. 

Note: For SSI, add 4 bytes to sizes given above. 



33 


21 


2 


35 


23 


2 


37 


25 


2 


39 


27 


2 
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SCATTER EXTENT LIST 



Bytes 



12 



16 



1 byte ^j<~ 



Hex. 80* 



EXLLNTH ( Total size of extent list ) 



Number of relocation factors 



Length of first non-contiguous block 



Length of second non-contiguous block 



Length of third non-contiguous block 



3 bytes 



Length of last non-contiguous block 



Address of first non-contiguous block 



Address of second non-contiguous block 



Address of third non-contiguous block 



Address of last non-contiguous block 



Indicates the end of the immediately preceding length-of-block 
list. Used by the GETMAIN routine. 
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BLOCK EXTENT LIST AND NOTE LIST 



0(0) 



4(4) 



X'80' 



X'OO' 



X'OO' 



- 4 bytes - 



EXLLNTH 
Total Size of Block Extent List 



Number of Relocation Factors 



Length of First Main Storage Block 



Length of Last Main Storage Block 



Address of First Main Storage Block 



Address of Lost Main Storage Block 



Block 
Extent 
List 



X'OO' 



Relocation Factor 



Relative Disk Address (TTR) of First Segment of Module 



Relative Disk Address (TTR) of Second Segment of Module 



Relative Disk Address (TTR) of Third Segment of Module 



Concatenation Number* 



Zero 



Zero 



Zero 



Note List 
(overlay 
modules only) 



Relative Disk Address (TTR) of Last Segment of Module 



Zero 



*ConcatenaI'ion number is a value that specifies this data set's sequential position 
in a group of concatenated data sets. 
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SCATTER/TRANSLATION RECX)RD 



2-3 



4-1023 



Up io and including 1020 bytes 



' — Data - may contain translation table, translation table and scatter table or scatter table only 
" Count - in bytes, of data field 

Zero - one byte of binary zeros 

Identification - identifies this as a scatter-translatlon record - bit configuration is: 0001 0000 

Translation Table 



L 



'1 



Padding (2 bytes) - if necessary, to force full-word boundary alignment of scatter table. 

Pointer (2 bytes) - to the scatter table entry that contains the address of the control section 

containing this CESD entry. 

Number of translation table entries = number of CESD entries + 1 . 

Pointer will be zero if its corresponding CESD entry ts not SD, PC, CM or LR. 

Zero - 2 bytes of binary zeros 

NOTE : (One 2-byte entry for each external symbol) 

Scatter Table 



^1 



I As: 



signed address (4 bytes) - of a control section (SD, PC or CM) (one entry for each CSECT) 



-Zero - 4 bytes of binary zeros 



Translation Table and Scatter Table 



' — Scatter data 
-Podding (2 bytes) if necessary to align scatter table to a full-word boundary. 

Translation data 

NOTE: Translation table foilows extent list in main storage. 

Translation table entries are two bytes in length, scatter table entries four bytes in length. 

Legend for Types of Entries in Composite External Symbol Dictionary (CESD) 

SD = section definition 
LR = label reference 
PC = private code 
CM = common 
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PROGRAM FETCH WORK AREA 



Offset 


Bits and 


Field 


Dec 


Hex 


Byte Pattern 


Name 








32 




32 


20 


8 




40 


28 


48 




88 


58 


24 




112 


70 


264 




376 


178 


40 




416 


lAO 


264 




680 


2A8 


40 




720 


2D0 


264 




984 


3D8 


40 




1024 


400 


4 




1028 


404 


4 




1032 


408 


8 




1040 


410 


36 




1076 


434 


64 




1140 


474 


4 




1144 


478 


4 




1148 


47C 


4 




1152 


480 


4 




1156 


484 


4 




1160 


488 


8 

Byte 
Byte 1 





Byte 2 



Byte 3 



Bytes 4-7 



Field Description, Contents. Meaning 

lOB - 8 fullwords. 

JOB seek address - 2 fullwords. 

SEEK BUFFERS (4) - 12 FULLWORDS. 

Search and TIC CCWs - 3 doublewords. 

RLD buffer 1-33 doublewords. 

Channel program 1-5 doublewords. 

RLD buffer 2-33 doublewords. 

Channel program 2-5 doublewords. 

RLD buffer 3-33 doublewords. 

Channel program 3-5 doublewords. 

I/O ECB - 1 fullword. 

ECB - 1 fullword. 

Buffer table pointer - 2 fullwords. 

Buffer table - 9 fullwords. 

Register save area - 16 fullwords. 

Address of translation table - 1 fullword. 

Address of scatter list - 1 fullword. 

Address of R-pointer - 1 fullword. 

Address of P-pointer - 1 fullword. 

Boundary word for relocation - 1 fullword. 

Fetch flags - 2 fullwords. 

Reserved. 

FF = program is being scatter-loaded. 
00 = progrcim is being block-^loaded. 

FF = all buffers are full. 

OF = Channel-End Appendage routine is unable to 
restart a channel program because all buf- 
fers were full when the channel-end inter- 
ruption occurred. 

00 = normal condition. There is at least one 
empty buffer. 

FF = end condition. Only termination processing 

by the Program Fetch routine is needed. 
OF = end condition. Buffer processing is needed. 

= a read operation was just completed. A text 
record, followed by an RLD or control record, 
was just read. The restart buffer is the 
last one to be filled. 
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1168 490 
1176 498 



Address = a read operation was just completed. 

An RLD or control record was read. The 
contents of the restart- seek address 
buffer are saved to be used when 
channel-program restart is needed. 

ECB list - 2 fullwords. 

Last table entry - 1 fullword. 



PROGRAM FETCH BUFFER TABLE 



Offset 


Bits 


and 


Field 


Dec 


Hex 


Byte 


Pattern 


Name 








1 

0000 

1000 


0000 
0000 




1 


1 


3 






4 


4 


1 






5 


5 


3 






8 


8 


1 






9 


9 


3 






12 


C 


1 






13 


D 


3 






16 


10 


1 






17 


11 


3 






20 


14 


1 






21 


15 


3 






24 


18 


1 






25 


19 


3 






28 


IC 


1 






29 


ID 


3 






32 


20 


1 






33 


21 


3 







Field Description, Contents, Meaning 

Buffer code. 

Buffer empty. 

Buffer full. 

Pointer to next entry (byte 12). 

TIC command. 

Address of channel program 2. 

Zero. 

Address of buffer 1. 

Buffer code (same as byte 0) . 

Pointer to next entry (byte 24). 

TIC command. 

Address of channel program 3. 

Zero. 

Address of buffer 2. 

Buffer code (same as byte 0) . 

Pointer to first entry (byte 0) . 

TIC command. 

Address of channel program 1. 

Zero. 

Address of buffer 3. 
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CONTROL RECORD 



1-3 



8-15 



Record length is 20 bytes 



■ Length of control section - specifies the length of the control section ( in bytes ) 
that the text in the following record belongs to (2 bytes) 



- CESD entry number - specifies the composite external symbol dictionary entry 
that contains the control section names of the control section that this 
text is part of ( 2 bytes ) 



Channel Command Word (CCW) - that could be used to read the text record that follows. 

The data address field contains the linkage editor assigned address of the first 
byte of text in the text record that follows. (8 bytes ) 

- Count - contains two bytes of binary zeros. The count field contains the length of the record. 



Count - in bytes of the control information (CESD ID, length of control section ) following the CCW 
field (2 bytes ) 

Spare - contains three bytes of binary zeros 

• Identification - specifies that this is: ( 1 byte ) 



•- A control record - 0000 0001 

• The control record that precedes the last text record of this overlay segment - 0000 0101 

• The control record that precedes the last text record of the module - 0000 1101 
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RELOCATION DICTIONARY (KLD) RECORD 



8-15 



16-255 



Record length can be between 24 and 
256 bytes 



■RLD data — see below 



' Spare - contains 8 bytes of binary zeroes 



Count - in bytes of the relocation dictionary information following the spare 8 byte field (2 bytes) 



~ Count - contains two bytes of binary zeroes 
' Spare - contains three bytes of binary zeroes 



" Identification - specifies that this is : (1 byte ) 

A relocation dictionary record - 0000 0010 
The last record of the segment - 0000 0110 
The last record of the module - 0000 1110 



RLD Data 



F 


A 


R 


P 


F 


A 


R 


P 


F 


A 
















Address 


. Lin 


kage 


editor as 



address of the address 
constant (3 bytes) 

Flag - specifies miscellaneous information as follows: (1 byte) when byte format is xxxxLIST: 

xxxx specifies the type of this RLD item (address constant) 

0000 — non-branch type in assembler language, a DC A (name) 

0001 — branch type (in assembler language, a DC V (name) 

0010 — pseudo register displacement value 

0011 — pseudo register cumulative displacement value 

1000 and 1001 — this address constant is not to be relocated, because it refers to an 
unresolved symbol. 

LL specifies the length of the address constant 
01 — two byte 

10 — three byte 

1 1 — four byte 
S specifies the direction of relocation 

— position 

1 — negative 
T specifies the type of RLD item following this one 

— the following RLD item has a different relocation and/or position pointer 

1 — the following RLD item has the same relocation and position pointers as this one, 
and therefore is omitted 



Position pointer - contains the entry number of the CESD entry (or translation table entry) that indicates which 

control section the address constant is in (2 bytes) 

- Relocation pointer - contains the entry number of the CESD entry (or translation table entry) that indicates which symbol's 
value is to be used in the computation of the address constant's value (2 bytes) 
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CONTROL AND RELOCATION DICTIONARY RECORD 



1-3 



6, 

7 



8-15 



' — Address 
I Flag 

' Address (3 bytes) 

• Flag ( 1 byte ) 
-Position pointer ( 2 bytes ) 
- Relocation pointer ( 2 bytes ) 
-Channel Command Word ( 8 bytes ) 



Count of RLD information ( 2 bytes ) 

Count of control information (2 bytes ) - the control information contains the 

ID and length of control sections in the following text record. 

— Spare (3 bytes ) 

•Identification ( 1 byte ) - specifies that this record is: 

• A control and RLD record - 0000 001 1 

• A control and RLD record that is followed by the 
last text record of a segment - 0000 01 1 1 

• A control and RLD record that is followed by the 
last text record of a module - 0000 1111 

Note: For detailed descriptions of the data fields see: 

Relocation Dictionary Record 
Control Record 

The record length will vary from 20 to 260 bytes. 



-Length of control section (2 bytes) 



CESD entry number (2 bytes) 



320 



SEGMENT TABLE 



Byt 


;s 
4 
8 
12 
16 
20 
24 
28 


TEST 
ind. 


Bit 1 = 0: Not in Test 
Bit 1 = 1: In Test 


Address of data control block (DCB) used to load module * 
1 







Address of note list * 




Last segment number of 
region 1 


Highest segment no. in 
storage- region 1 
9 


Last segment 
number of region 2 
10 


Highest segment no. in 
storage-region 2 
11 




Last segment number of 
region 3 


Highest segment no. in 
storage-region 3 
13 


Lost segment 
number of region 4 
14 


Highest segment no. in 
storage- region 4 
15 




Addre 


>s of ECB to be posted when SEGLD request has been serviced * 




Reserved * 




Previous segment * 
number for segment 1 


Status 
25 '"'^'^*' 




Previous segment 
number for segment 2 


Address of entry table entry (when caller chain exists) * 
29 


Status 
Indrctr 




1 




Previous segment number 
for segment N 


Address of entry table entry (when caller chain exists) * 


Status 
Indctr 



4 bytes 



Offset 
Dec Hex 



Bits and Field 
Byte Pattern Name 



1 1 

4 4 

5 5 

8 8 

9 9 



10 
11 



A 

B 



3 

1 
3 

1 
1 

1 
1 



Field Description, Contents. Meaning 

TEST indicators. 

Module is "under test" using TESTRAN. Initia- 
lized by Program Fetch routine. 

= not in Test. 

1 = in Test. 

Address of DCB used to load module. 

Zero. 

Address of note list. 

Last segment number of region 1. 

Highest segment number in storage-region 1. 
(Initially set to 01 by linkage editor.) 

Last segment number of region 2. 

Highest segment number in storage-region 2. 
(Initially set to 00.) 
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12 


C 


1 


13 


D 


1 


14 


£ 


1 


15 


F 


1 



16 



28 
29 



10 



20 


m 


i» 


2U 


18 


1 


25 


19 


3 



IC 
ID 



Variable 
Variable 



1 
3 

1 
3 



Last segment number of region 3. 

Highest setment number in storage- region 3. 
(Initially set to GO.) 

Last segment number of region 4. 

Highest segment number in storage- region 4. 
(Initially set to 00.) 

Address of ECB to be posted idien SEGLD request 
has been serviced. 

Reserved. 

Previous segment nu0±>er for segment 1. 

Address of entry table entry. Last two bits ind- 
icate status of segment: 

00 = segment is in main storage as a result of a 

branch to the segment. 

01 = segment is not in main storage, but is 

scheduled to be loaded. 

10 = segment is in main storage, no caller chain 

exists . 

11 = segment is not in main storage. (Initially 

set to 10.) 

Previous segment number for segment 2. 

Address of entry table entry. Status bits 
initialized to 11. 

Previous segment number for segment n. 

Address of entry table entry, status bits 
initialized to 11. 



♦Set to zero by linkage editor. 

Note ; "Region" refers to the regions of a multiregion overlay structure, not to a job 
step's region of main storage (see Linkage Editor SRL) . 
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ENTRY TABLE 



UncondiHonal branch to last entry- 
BC 15, D1SP(15,0) 



Address of referred to symbol 



"to" seg 
number 



Previous Caller 
(zero initially) 



12 



Unconditional branch to last entry - 
BC 15, DISP(15,0) 



Address of referred to symbol 



16 



"to" seg 
number 
20 



21 



Previous Caller 

(zero initially) 

22 



23 



Unconditional branch to last entry- 
BC 15, DIPS (15,0) 



Address of referred to symbol 



"to" seg 
number 



Previous Caller 
(zero initially) 



Last 
Entry 



SVC 45 
instruction 



L 15,4(0,15) Loads GR15 with 
the value of the ADCON. 



BCR 15,15 



"from" 
seg no. 



Address of segment 
table (SEGTAB) 



2 bytes 



2 bytes 



2 bytes 



2 bytes 



;1 byte >■ 



3 bytes 



NOTE: DISP = is the displacement, in bytes, of this entry from the last entry. 

"to" segment number — is the number of the segment containing the symbol being referred to. 
"from" segment number — is the number of the segment that contains this entry table. 
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SUBPOOL QOEDE ELEMENT (SPQE) 



Offset 
Dec Hex 



Bits and 
Byte Pattern 

1 



I ■ « X X3CX3C 



Field 
Name 



SPQEPTR 

SPID 
DQEPTE 



Field Description, Contents, Meaning 
Flags . 

= subpool belongs to associated task. 

1 = subpool is shared. 

Elonent is last SPQE on queue. This bit is usu- 
ally zero. 

Subpool shared with another task. 
Reserved. 

Pointer to next SPQE. When zero, this element is 
last SPQE on queue. 

Identifying number of subpool. 

Pointer to first DQE for subpool. If subpool 
shared, field points to "owning" SPQE. 



DESCRIPTOR QUEUE ELEMENT (DQE) 



Offset 


Bits 


and 


Field 


Dec 


Hex 


Byte 


Pattern 


Name 








1 






1 


1 


3 




FQEPTR 


H 


4 


1 






5 


5 


3 




DQEPTR 


8 


8 


1 
xxxx 

.... 


XXX. 
X 


DQEHRID 



9 9 3 

12 C 1 

13 D 3 



Field Description, Contents, Meaning 

Reserved. 

Pointer to first free area (first FQE) , or zero 
if entire block is allocated. 

Reserved. 

Pointer to next DQE. zero in last DQE. 

Flags. 

Zero. 

= DQE describes storage obtained from hierarchy 

0. 

1 = DQE describes storage obtained from hierarchy 

1. 

Address of the first 2K block described by this 
DQE. 

Reserved. 

Length in bytes described by this DQE. (Always a 
multiple of 2K bytes.) 
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FREE QOEOE ELEMENT (FQE) 



Offset 
Dec Hex 



1 1 
H 4 
5 5 



Bits and 
Byte Pattern 

1 

3 

1 

3 



Field 
Name 



FQEPTR 



LENGTH 



Field Description, Contents. Meaning 

Reserved. 

Pointer to next lower free area. 

Reserved. 

Number of bytes in free area. 



ALLOCATED QUEUE ELEMENT (AQE) 



Offset 
Dec Hex 



1 1 

4 4 

5 5 



Bits and 
Byte Pattern 

1 

3 

1 
3 



Field 
Name 



AQEPTR 



LENGTH 



Field Description. Contents, Meaning 

Reserved. 

Pointer to next allocated area. 

Reserved. 

Number of bytes in allocated areas. 
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GOVRFLB (ORIGIN LIST FOR MAIN STORAGE QDEUES) 



Offset 
Dec Hex 



Bits and 
Byte Pattern 



1 


1 


3 


4 


4 


1 


5 


5 


3 


8 


8 


1 


9 


9 


3 


12 


C 


1 


13 


D 


3 


16 


10 


1 


17 


11 


3 


20 


14 


1 


21 


15 


3 



Field 
Name 



SQBOUND 



DQESQES 



PQEPTR 



24 18 



SZDPRS 



SZDLCS 



COUNT 



VQEPTR 



NIPSQSBD 



Field Description, Contents, Meaning 

X*80* = 2K of SQA not available to initiate a job 
in a region. 

Address of first byte beyond system queue area. 

Reserved. 

Address of the DQE describing the system queue 
area. 

Reserved. 

Address of a dummy PQE minus 8 bytes. The dummy 
PQE points to the PQE describing unassigned main 
storage (storage not assigned to any region). 

Reserved. 

Amount of storage available in hierarchy after 
NIP. 

Reserved. 

Smount of storage available in hierarchy 1 after 
NIP. 

Number of "VARY STORAGE, OFFLINE" commands in 
master scheduler region. 

{M65MP only) address of the first VQE describing 
storage areas scheduled for removal in a multi- 
processing system. Zero if no VQEs exist. 

Address of first byte beyond system queue area 
(used only by Rollout/Rollin) . 
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PARTITION QUEUE ELEMENT (PQE) 



Offset Bits and Field 
Dec Hex Byte Pattern Name 

4 PQEFFBQE 



PQEBFBQE 



8 8 

12 C 

16 10 

20 in 

2« 18 

28 IC 



29 ID 



4 




PQEFPQE 


n 




PQEBPQE 


n 




PQETCB 


n 




PQESIZE 


4 




PQEREGN 


1 




PQERFLGS 


.1.. 


.... 




..1. 


• • • • 




...1 


• « • • 




* « • • 


xxxx 




1 




PQEHRID 


xxxx 


XXX. 




• « • • 


« • • X 
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Field Description, Contents, Meaning 

Address of first FBQE in region described by this 
PQE. If there are no FBQEs, contains the PQE 
address. 

Address of last FBQE in region described by this 
PQE. If there are no FBQEs, contains the PQE 
address. 

Address of next PQE on queue. Contains zeros in 
last PQE. 

Address of preceding PQE on queue. Contains 
zeros in first PQE. 

Address of TCB for the job step to which the 
space belongs. Contains zeros if the space was 
obtained from unassigned free space. 

Size of region described by this PQE. (Always a 
multiple of 2048.) 

Address of first byte of region described by this 
PQE. 

Rollout flags. 

= space described by this PQE is owned. 

1 = space is borrowed. 

Region has been rolled out. Meaningful only if 

bit 0=0. 

Region is in use by borrower. Meaningful only if 

bit 0=0. 

Region cannot be rolled in due to a machine 

check. 

Reserved. 

Hierarchy identifier. 

Zero. 

= PQE describes region in hierarchy 0. 

1 = PQE describes region in hierarchy 1. 

Reserved. 
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DUMMY PARTITION QUEUE ELEMENT (DPQE) 



Offset Bits and Field 
Dec Hex Byte Pattern Name 



4 
4 4 4 
Relationship of Dummy PQE to TCB and PQE Chain 



Field Description, contents. Meaning 
Address of first PQE on chain. 
Address of last PQE on chain. 



TCB 




Dummy PQE-8 
Dummy PQE 



PQE 



PQE 



PQE 




FREE BLOCK QUEUE ELEMENT (FBQE) 



Offset 


Bits 


and 


Field 


Dec 


Hex 


Byte 


Pattern 


Name 








1 






1 


1 


3 




FWDPTR 


4 


4 


1 






5 


5 


3 




BCKPTR 


8 


8 


1 






9 


9 


3 




SIZE 



Field Description, Contents, Meaning 

Reserved. 

Pointer to the next higher address FBQE in the 
region. In the highest address FBQE, contains 
the address of the PQE. 

Reserved. 

Pointer to the next lower FBQE in the region. In 
the lowest FBQE, contains the address of the PQE. 

Reserved. 

Number of bytes in the set of 2K blocks. 



ROLLOUT I/O QUEUE ELEMENT (RIQE) 



Offset 


Bits and 


Field 


Dec 


Hex 


Byte Pattern 


Name 








4 




4 


4 


4 




8 


8 


4 




12 


C 


4 





Field Description, Contents, Meaning 
Address of next RIQE. 
Address of rolled-out job step's TCB. 
Address of I/O- purged TCB. 
Beginning of address of lOB chain. 
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REPLY QUEUE ELEMENT (NON-MCS) 



Offset 
Dec Hex 


Bits 
Byte 


and 
Pattern 


Field 

Name 








4 




RQERQE 


4 


4 


2 




RQELD 


6 


6 


2 

Byte 
1... 

..1. 

.X. X 

Byte 




• • • ■ 

• • • • 

XXXX 

1 


RQEXA 


8 


8 


1 




RETJIDl 


9 


9 


3 




RQETCB 



12 



16 


10 


1 


17 


11 


3 


20 


14 


1 


21 


15 


3 



RQEXB 

RQELNTH 
RQERPTR 
RQETJID2 
RQEECB 



Field Description. Contents. Meaning 
Address of next reply queue element. 
Reply identification number. 
Flags. 

Associated reply will be purged. 
Associated task has been rolled out. 
Reserved. 

Reserved. 

First half of TSO user ID for swapped-out task. 

Address of TCB for task that issued message for 
which this RPQE represents a reply. 

Address of purging message buffer, or temporary 
buffer if reply was deferred by rollout. 

Maximum length of reply. 
Address of user's buffer- 
Second half of TSO user ID for swapped-out task. 
Address of user's ECB. 



REPLY QUEUE ELEMENT (MCS) 



Offset 


Bits 


and 


Dec 


Hex 


Byte 


Pattern 








4 




4 


4 


2 




6 


6 


1 








1... 


• • • • 






..1. 


• « « • 






.x.x 


XXXX 


7 


7 


1 








1... 


• « • • 






.1.. 


• • • • 






...1 


• • • • 






• • • • 


1... 






. .X. 


.XXX 


8 


8 


1 




9 


9 


3 





Field 
Name 

RQELKP 

RQEID 

RQEXA 



12 



RQEAVAIL 

RQEBUFA 
RQEBUFB 
RQEBUFD 
RQEBUFE 



RETJIDl 
RQETCB 

RQEXB 



Field Description. Contents, Meaning 

Address of next reply queue element. 

Reply identification number. 

Purge flags. 

Associated reply will be purged. 
Associated task has been rolled out. 
Reserved. 

Buffer flags. 

Buffer is free. 

Buffer is in use. 

Buffer has been obtained dynamically. 

Buffer has been serviced. 

Reseirved. 

First half of TSO user ID for swapped-out task. 

Address of TCB for task that issued message for 
which this RPQE represents a reply. 

Address of communications task emergency message 
to cancel replies. 
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16 


10 


1 


17 


11 


3 


20 


14 


1 


21 


15 


3 



RQELNGTH Maximuin length of reply. 

RQEPTR Address of user's buffer. 

RETJID2 Second half of TSO user ID for swapped-out task. 

RQEECB Address of user's ECB. 



SVC PORGE PARAMETER LIST 



Offset 
Dec Hex 



12 



Bits and 
Byte Pattern 



113 
H H 1 

5 5 3 



1 

X. . 
.X. 



Field 
Name 

PURGOPT 



PURGDEB 

PORGTCB 
PURGECB 



PURGIOB 



PRGFGL 



.X xxxx 



13 D 3 



PRGQPL 



Field Description, Contents. Meaning 

Purge options (always X'02' for rollout, request- 
ing 'TCB' and 'quiesce' options). 

Address of DEB (not used for rollout) . 

Completion code to be placed in ECB. 

During input: address of TCB whose request ele- 
ments are to be purged. 

During output: address of ECB to be posted when 
purge is complete. 

Count field for quiesce option. Number of requ- 
est elements whose I/O operations have not yet 
completed. 

Address of an lOB chain field. The lOBs queued 
from the chain field represent channel programs 
to be restarted by the SVC Restore routine after 
rollin has occurred. These lOBs belong to the 
task whose TCB address is recorded in the PURGTCB 
field. 

Purge flags. 

= purge entry. 

1 = wait entry. 

= return before wait. 

1 = purge and wait. 

= DEQ before wait. 

1 = no DEQ before wait (set before system DEB 

purged) . 
Reserved. 

Address of quiesce I/O parameter list. 
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TIMER QUEUE ELEMENT (TQE) 



Offset Bits and 
Dec Hex Byte Pattern 



• • jLX. • • • < 



,1.. 

. .XX 



Field 
Name 

TQEFLGS 



4 
5 

8 
9 

12 



16 



20 



24 



25 



28 



29 



1 3 

4 1 

5 3 

8 1 

9 3 

C 4 



10 



14 



18 



19 



IC 



ID 



♦5-7 

TQETCB 

TQEFLNK 

TQEBLNK 
TQEVAL 



32 20 64 



TQEPSW 

TQESAV 

TQETJIDl 

TQESAADR 

TQETJID2 

TQEEXIT 

TQEGRS 



Field Description, contents. Meaning 

Flags . 

Timer element is not on timer queue. 
Local TOD option used. 

00 = TUINTVL requested. 

01 = BINTVL requested. 

10 = reserved. 

11 = DECINTVL requested. 
Interval is complete. 
Exit specified.* 

00 = task request. 

01 = wait request. 

10 = supervisory request.* 

11 = real request. 

110 = midnight supervisory timer element. 

Address of the TCB for the task for which this 
timer element is being used. 

Zero. 

Forward link field. Contains the address of the 
first byte of the next TQE on the timer queue. 

Zero. 

Backward link field. Contains address of first 
byte of previous TQE on timer queue. 

Interval value. If the element is on the timer 
queue, this field represents the time of expira- 
tion (TOX) of the interval relative to the 6-hour 
interval. If the element is off the timer queue, 
this field represents the remaining time in the 
interval. The value of the interval in microse- 
conds can be calculated by multiplying by 26 the 
decimal value represented ty the field. 

First word of current PSW - used when TQE serves 
as IRB. 

Used to save contents of TQEVAL when TQE is con- 
verted from TASK to REAL. 

First half of TSO user ID (when user not in main 
storage) . 

Address of the problem program register save 
area. 

Second half of TSO user ID (when user not in main 
storage) . 

Exit routine address. Contains the address of 
the timer exit routine if one was specified by 
the user in the calling sequence of the STIMER 
macro instruction. Otherwise, the field is zero. 

General register save area. This field becomes 
the general register save area when the TQE is 
used as an IRB for the scheduling of a timer exit 
routine. 
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96 60 16 TQEECB Event control block to be posted for a "wait" 

type interval. Used for ECB when WAIT parameter 
given in STIMER macro instruction. 
TQEIQE Interruption queue element passed to Stage 2 Exit 
Effector to schedule a timer exit routine. Used 
for interruption queue element when TQE serves as 
IRB. 

A TQE is required in systems with the time-slicing feature. It is used by the Dis- 
patcher to set the time interval to the specified time-slice length when a time-sliced 
task is dispatched. The first 16 bytes of the TQE are used in this application. 
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SECONDftRY COMMDNICATIONS VECTOR TABLE (SCVT) 

This table appears in module lEAQETOO, beginning at symbolic location lEABEND. It 
consists of a list of address constants that point to routine entry points or system con- 
trol blocks. 



Offset 


Bits 


and 


Field 


Dec 


Hex 


Byte 


Pattern 


Name 








4 




SCVTPGTM 


H 


4 


4 




SCVTPGWR 


8 


8 


4 




SCVTSPET 


12 


C 


4 




SCVTACT 


16 


10 


4 




SCVT ERAS 


20 


14 


4 




SCVTQCBO 


2H 


18 


4 




SCVTPGEQ 


28 


IC 


4 




SCVTRMBR 


32 


20 


4 




SCVTPGIO 


36 


24 


4 




SCVTRACE 


40 


28 


4 




SCVTTASW 


HH 


2C 


4 




SCVTCDCL 



48 



52 



30 



34 



56 


38 


4 


60 


3C 


4 


64 


40 


4 


68 


44 


4 


72 


48 


4 


76 


4C 


4 


80 


50 


4 


84 


54 


4 


88 


58 


4 


92 


5C 


4 


96 


60 


4 


100 


64 


4 



SCVTLFRM 

SCVTPABL 

SCVTDQTC 
SCVTHSKP 
SCVTRPTR 
SCVTGMBR 

SCVTAUCT 

SCVTROCT 

SCVTROQ 

SCVTRIRB 

SCVTRTCB 

SCVTCOMM 

SCVTABLK 
SCVTNFND 



Field Description, contents. Meaning 

Address of EOT Purge Timer routine (lEAQPGTM) . 

Address of WTOR Purge routine (lEECVPRG) . 

Address of Release Main Storage routine 
(lEAQSPET). 

Address of TACT (lEAQTAQ) . 

Address of EOT Erase Phase routine (lEAQERA). 

Address of QCB origin (lEAQQCBO) . 

Address of ENQ/DEQ Purge routine (lEAOEQOl). 

Address of REGMAIN branch entry (RMBRANCH) . 

Address of SVC Purge routine (IGC016). 

Address of Trace routine switch (lECXTRA) . 

Address of Task Switching routine (IEA0DS02) . 

Address of CDCONTRL in common subroutines of Con- 
tents Supervision (IEAQCS02) . 

Branch entry-point to FREEMAIN routine 
(FMBRANCH) . 

Address of Release Loaded Programs routine (lEA- 
QABL) in EOT. 

Address of Dequeue TCB routine (lEADQTCB) in EOT. 

Address of CDHKEEP (CDHKEEP) in CDEXIT routine. 

Address of trace table pointers (TRPTR) . 

List format GETMAIN branch entry-point 
(GMBRANCH) . 

Transient area user count (TADSERCT) . 

Address of rollout counters (lEARCTRS) . 

Address of rollout queue (lEAROQUE) . 

Address of rollout IRB (lEAROIRB). 

Address of rollout TCB (lEAROTCB) . 

Address of Communications Task routine (lEECVCTW) 
for DAR. 

Entry to ABTERM routine (SCEDWAIT) for DAR. 

Entry to Transient Area Handler routine 
(TBNOTFND) for DAR. 
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104 


68 


4 


108 


6C 


4 


112 


70 


4 


116 


74 


4 


120 


78 


4 


124 


7C 


4 


128 


80 


4 


132 


84 


4 


136 


88 


4 


140 


8C 


4 


144 


90 


4 


148 


94 


4 


152 


98 


4 
Byte 

J.aaa •«•• 

•Xaa •••• 

... X xxxx 

Bytes 1-3 



SCVTRMTC 

SCVTMSSQ 

SCVTCTCB 

SCVTETCB 

SCVTRXLQ 

SCVTRQND 

SCVTTAR 

SCVTSVCT 

SCVTSTXP 

SCVTTQE 

SCVTJIMSV 

SCVTFMSA 



SCVTSWl 
SCVTSW2 

SCVTSW3 



Address of RMS TCB (IGFRMTCB) . 

Address of GOVRFLB. 

Address of Coininunications Task TCB (lEECVTCB), 

Address of System Error TCB (lEARTCB) . 

Address of recovery extent list. 

Address of end of I/O RQE table (lECITSAR). 

Address of Transient Area Refresh routine. 

Address of SVC table (IBMORG). 

Address of STAX Purge routine (lEAKJXP) . 

Address of TSO subsystem TQE (lEATSELM). 

Address of SVC 85 instruction (lORMSSVC). 

Reserved . 



Conditional branch entry to FREEMAIN. 

Branch entry to IGC003 from ABEND requires use of 

conditional FREEMAIN for unprotected storage. 

Branch entry to SVC 5 type FREEMAIN (internal to 

IGC003). 

Reserved. 

Address of FREEMAIN register (2-14) save area 
(lEAlOFS) . 
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ABDUMP PARAMETER LIST 



Off 
Dec 


set 
Hex 




Bits 
Byte 


and 
Pattern 





1 




1 


1 


1 




2 


2 


2 








Byte 




« « • • 



1) 

5 
8 

9 
12 
13 



H 
5 
8 

9 
C 
D 



1.. 
1. 



1. 

1 



Byte 1 



1. . 
1 . 
- 1 



1 
3 
1 



1.. 
1. 



XXXX XXX. 

3 

1 
3 



Field 
Name 



PFABEND 

PFTCB 

PFSDPDAT 

PFTRACE 

PFNUC 

PFSNAP 

PFID 

PFQCB 



PFSAVE 
PFSAVE2 

PFREGS 

PFLPA 

PFJPA 

PFPSW 

PFSPALL 



Field Description, Contents, Meaning 

ID. 

Zero. 

Option flags. 



= ABEND request 

1 = SNAP request. 
TCB address is given. 
Display all supervisor data. 
Display trace table (if possible). 
Display the nucleus. 

Snapshot list is given. 
ID given. 
Display the QCBs. 



Save area (see next flag) . 

= display entire save area. 

1 = display headings only. 

Display registers on entry to ABEND or SNAP. 

Display link pack area. 

Display job pack area. 

Display PSW on entry to ABEND or SNAP. 

Display all subpools less than subpool 128. 

Reserved. 

Zero. 

Pointer to DCS. 



Zero. 

SDDMP request. 

Pointer to TCB. 

Zero. 

Pointer to storage list. 
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TIME-SLICE CONTROL ELEMENT (TSCE) 

There is one TSCE for each priority that is time- sliced. The address of the first 
TSCE is in the CVTTSCE field of the CVT. All TSCEs are contiguous. 



Offset 
Dec Hex 





1 

4 
5 

8 
9 

12 
13 





1 

4 
5 

8 
9 



Bits and 
Byte Pattern 

1 

3 

1 
3 

1 
3 



Field 
Naire 



.XXX xxxx 

3 



Field Description. Contents, Meaning 

Dispatching priority of time-slice group. 

Address of first TCB on TCB queue that is a memb- 
er of the time-slice group. 

Zero. 

Address of last TCB on TCB queue that is a member 
of the time-slice group. 

Zero. 

Address of next TCB to be dispatched when the 
priority obtains control. 

TSCE flags. 

Last TSCE. 
Reserved. 

Length of time-slice. In milliseconds before 
NIP; in timer units after (26.04166 micro-seconds 
per timer unit) . 
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DISPIAY CONTROL MODULE (PCM) 

The DCM is composed of a resident portion (RDCM) and a transient portion (DDCM) which 
may be resident or transient at the user's option. 



RESIDENT DISPLAY CONTROL MODULE (RDCM) 



The RDCM contains screen control information and the address of the main storage area 
assigned to the TDCM. If the TDCM is transient, this main storage area may be used for 
the TDCMs of several consoles. 

The RDCM may also contain one or more screen area control blocks. These control 
blocks contain information about each status display area defined for the screen. 



Offset 
Dec Hex 



Bits and 
Byte Pattern 



Field 
Name 

DCMADTRN 



DCMINDEX 



DCMRFLGS 







1... 


« • • • 


DCMREAD 






-1.. 


« • « • 


DCMTYPE 






..1. 


• • • • 


DCMWRITE 






...1 


• • • • 


DCMDOM 






• • • • 


1... 


DCMNIPP 






• « • • 


..1. 


DCMFRSRD 






• • • • 


...1 


DCMSRCH 


6 


6 


2 




DCMLEN 


8 


8 


4 




DCMADKP 


12 


C 


1 




DCMTOPAR 


13 


D 


1 




DCMTOPDS 


in 


E 


1 




DCMRESTA 






1... 


• • • • 


DCMATTN 






.1.. 


• • ■ • 


DCMOPNSV 






. .XX 


xxxx 




15 


F 


1 




DCMDEVTY 






1... 


... a 


DCMTY60 






.1.. 


.... 


DCMTY50 






. .XX 


xxxx 




16 


10 


n 




DCMADSDS 


20 


m 


1 




DCMRMS 



Field Description, Contents. Meaning 

Address of the main storage area assigned to the 
TDCM. 

Display console identification number assigned by 
the Graphic Console Initialization routine. 

Display console status flags. 

DCM read in process. 
Console uses transient DCMs. 
DCM write in process. 
DOM must be tried. 
DCM was used by NIP. 
First read of DCM. 
Processor routing flag. 

Length of the transient portion of the DCM. 

Address of routed K command parameter list. 

Address of the top-most display area defined for 
the screen. 

Address of the top-most display area that is in 
use (contains a display) . 

Flags for attention and open requests. 

Attention status has been saved. 
Open status has been saved. 
Reserved. 

Device type flags. 

Device is a 2260. 
Device is a 2250. 
Reserved. 

Pointer to the first screen area control block. 
Zero if no display areas are defined for the 
screen. 

Recovery management support (RMS) information. 
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21 


15 


3 


24 


18 


4 


28 


IC 


2 


30 


IE 


2 


32 


20 


4 


36 


24 


4 


40 


28 


2 


42 


2A 


2 


44 


2C 


1 



1... 
1.. 
1. 



.1 .. 

,. 1, 



45 



2D 



1... 
.1.. 
.-1. 
...1 



xxxx 



46 



2E 



DCMADRMS Address of RMS channel progreims. 

DCMWLAST Address of last console queue entry to be 
displayed. 

DCMRMSAL Number of lines in message area. 

Reserved. 

DCMMSGSV Address of a list of saved NIP messages. 

DCMADPFK Address of the resident PFK area. 

DCMINTVL Time interval for the DCM. 

DCMTMCTR Time counter for the DCM. 

DCMR2FLG Timer flags. 

DCMRXSFL Full screen. 

DCMRXDNV Dnviewable message displayed. 

DCMRXTMR Timer flag. 

DCMRXRLL Ready to roll. 

DCMRXDEL Pending delete request. 
Entry was from options. 

DCMBXTIM Timer elapsed for this display. 

DCMRXDCM TDCM is in storage. 

DCMR3FLG Flags. 

DCMSTSWT Changing status of output-only console. 
DCMKVIP Entry for K VARY command. 
DCMCLPR Close in process. 

Asynchronous error message on screen. 

Reserved. 

Reserved. 



Offset 


Bits and 


Dec 


Hex 
30 


Byte Pattern 


48 


2 


50 


32 


2 


52 


34 


4 


56 


38 


1 



Screen Area Control Block (SACB) - one complete SACB is created for each display area 
defined for the screen; if no display areas are defined, no SACBs are created- SACBs may 
be contiguous with the RDCM, or may be chained to the RDCM by pointers. 

Field 

Name Field Description. Contents, Meaning 

DCMPLN Length of the display area in bytes. 

DCMPLNPR Length of the SACB in bytes. 

DCMACBNX Address of the next SACB. 

DCMAID Alphabetic identifier assigned to the display 
area. 

DCMASACB SACB flags. 

DCMAUSE SACB in use. 

DCMAGM SACB space obtained by GETMAIN. 
Reserved. 

DCMALN Length of the display area in bytes. 

DCMATOP Line number of the top line of the display area. 

DCMAROW Line number of the line to be written next. 

DCMAFR Frame number of the frame being displayed. 



57 



39 







. .XX xxxx 


58 


3A 


2 


60 


3C 


1 


61 


3D 


1 


62 


3E 


2 
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64 40 



68 44 



72 48 



74 4C 



76 4E 



77 



4F 



78 



50 



..1. 


« • • • 


XX. X 


xxxx 


1 




1... 


« • • • 


• 1.. 


• • • « 


..1. 


« • • • 


...1 


• • • • 


• • a • 


1... 


• • • • 


.1.. 


• • • • 


. .XX 


1 




1... 


• • • • 


.1.. 


• • • • 


..1. 


• • « • 



XXXX 



• • « X. X.XX.X. 



79 



51 



DCMAMJWQ Address of the console queue entry for the major 
WQE. 

DCMAMIN Address of the console queue entry for the minor 
WQE being written. 

DCMATIME Time indicator written in the control line of the 
display being written. 

DCMAMT Message type flag. 

DCMAMTC Monitor active. 
Reserved. 

DCMAFLGl Display area flags. 

Display coming to area. 
DCMADISP Display in area. 
DCMADEND End of display on screen. 
DCMAFRPR Framing in process. 
DCMAFULL Frame full. 
DCMABL Blanking to be done. 

Reserved. 

DCMAFLG2 Display area status flags. 

DCMALMIN Saved pointer to last minor output. 
DCMAWCON Write control line. 
DCMARCON Rewrite control line. 
DCMAMJFR Major WQE has been found. 
Reserved. 

DCMADFLG Display flags. 

DCMADD Dynamic display. 
DCMAHOLD Dynamic display in hold mode. 
DCMACSIB Dynamic display with control line in SIB. 
Reserved. 

Reserved. 
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TRANSIENT DISPLAY CONTROL MODULE (TDCM) 



The TDCM contains two sections: the "device independent" section and the "device 
dependent" section. The device independent section is the same size and form for all 
display devices; the device dependent section varies according to the device it is 
supporting. 

Device Independent Section ; These areas comprise save areas, work areas and communica- 
tions task information- 



Offset 
Dec Hex 



Bits and 
Byte Pattern 

2 

2 



Field 
Name 



4 


4 


1 






DCMFLGl 






• • 


.1 


• • • • 


DCMQOE 






• • 


• • 


..1. 


DCMOUTPT 






XXX. 


XX. X 




5 


5 


3 








8 


8 


4 






DCMWTINT 


12 


C 


4 








16 


10 


4 






DCMPACK 


20 


14 


4 






DCMCVBIN 


2H 


18 


1 






DCMTIMES 






1. 




• • • • 


DCMTIMER 






.1 


« a 


« • • • 


DCMOPTTI 








1. 


• « • • 


DCMGROLL 








.1 


• • • • 


DCMOTTMM 








« a 


1... 


DCMSTTMR 








. a 


.1.. 


DCMASYN 








• • 


..1. 


DCMOCTTI 








• • 


...1 


DCMRMl'TI 


25 


19 


1 








26 


lA 


2 






DCMELGN 


28 


IC 


4 






DCMBUFAD 


32 


20 


4 






DCMDOMPK 


36 


24 


4 






DCMAMTAB 


40 


28 


4 






DCMADSEC 


HH 


2C 


4 






DCMADDRL 


48 


30 


4 






DCMASCRN 


52 


34 


4 






DCMLSCRN 


56 


38 


4 






DCMWTBUF 



Field Description, contents. Meaning 

Length of TDCM. 

Reserved. 

TDCM flags. 

Queue this DCM for WRITE. 
DCM updated for output only. 
Reseirved. 

Reserved. 

Initial value for DCMWTBUF. 

Reserved. 

Area used for packing decimal digits. 

Area used for conversion to binary. 

Timer routine flags. 

Time elapsed for this display. 

Options to Timer routine. 

Display ready to roll. 

Option to Timer routine to message module. 

STIMER should be issued. 

Timer set for asynchronous error message. 

OPEN-CLOSE to Timer routine. 

Roll mode to Timer routine. 

Reserved. 

Pointer to the last character in the entry area. 

Address of buffer address table. 

Address of first DOM number. 

Address of first screen control table entry. 

Address of first secondary screen control table 
entry. 

Address of last screen control table entry. 

Address of screen image buffer. 

Address of last screen image buffer line. 

Address of the PFK number line (or the blank line 
between the message area and the instruction line 
on display consoles that do not support light pen 
command entry) in the screen image buffer. 
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60 



64 



68 



3C 



40 



HH 



72 


48 


4 


76 


4C 


4 


80 


50 


4 


84 


54 


4 


88 


58 


20 


108 


6C 


2 


110 


6E 


2 


112 


70 


128 


240 


FO 


8 


248 


F8 


2 


250 


FA 


2 


252 


FC 


2 


254 


FE 


2 


256 


100 


2 


258 


102 


2 


260 


104 


2 


262 


106 


2 


264 


108 


2 


266 


lOA 


2 


268 


IOC 


2 


270 


lOE 


2 


272 


110 


1 


273 


111 


1 


274 


112 


2 


276 


114 


1 



277 115 



278 116 



DOMAINS Address of the instruction line in the screen 
image buffer. 

DCMAENTR Address of the entry area in the screen image 
buffer. 

DCMAWARN Address of the warning line in the screen image 
buffer. 

DCMADCHP Address of the channel program area. 

DCMPFKLN Reserved. 

DCMCXSVE CXSA save area. 

DCMADOPN Address of the command operand. 

DCMDSAV Command save area and work area. 

DCMINLGN Input length. 

DCMMCSFL Space for MCS flags. 

DCMINPUT Space for input message text. 

DCMRQDEL Buffer for pending delete requests. 

DCMLGNTH Length of a line. 

DCMBAINC Position of cursor in screen image buffer. 

DCMIRCTR Intervention requested message counter. 

DCMBADLN Location in buffer to begin writing message. 

DCMBYTCT Number of bytes to write. 

DCMADNUM The line number to be assigned to the next line. 

DCMAXLGN Maximum line length. 

DCMMSGAL Number of lines in the message area. 

DCMRMINC RMI information. 

DCMSCTCN Length of one SCT entry. 

DCMCORLN Length of DCM line in main storage. 

Reserved. 

DCMPFKNM Number of the PFK key being processed. 

DCMPFKKN Number of the PFK key, in a list of PFK keys, 
that is being processed. 

DCMDEL Contains the current value of the DEL parameter 
of the CONTROL S command (Y or N) . 

DCMCON Contains the current value of the CON parameter 
of the CONTROL S command (Y or N) . 

DCMSEG Contains the current value of the SEG parameter 
of the CONTROL S command (numerical value) . 

DCMDL Contains the current value of the DL parameter of 
the CONTROL S command (numerical value) . 
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279 


117 


1 




DCMSNUM 


280 


118 


2 




DCMRTME 


282 


llA 


1 




DCMSEGDF 


283 


IIB 


1 




DCMRNDMD 


284 


lie 


2 




DCMRTMED 


286 


HE 


1 




DCMASKEN 


287 


IIF 


1 




DCMASKCN 


288 


120 


1 




DCMASKCR 


289 


121 


1 




DCMASKLP 


290 


122 


1 




DCMASKPF 


291 


123 


1 




DCMOPTST 






1... 


• • • • 


DCMOPTVR 






.1.. 


• • • • 


DCMOPTAD 






..1- 


• « • • 


DCMOPTSG 






...1 


« • • • 


DCMOPRLL 






• • • • 


xxxx 




292 


124 


1 




DCMCS 






1... 


• • « • 


DCMCSC 






.1.- 


• • • • 


DCMCSO 






. .XX 


xxxx 




293 


125 


1 




DCMUTILT 


294 


126 


1 




DCMDSTAT 






1... 


• • • • 


DCMDSTFL 






.1.. 


« • • • 


DCMUNVW 






..1. 


• « • • 


DCKflDSTNM 






...1 


• • • • 


DCMDSTNH 






• • • • 


1... 


DCMDSINR 






• ■ • • 


.1.. 


DCMDSAUT 



295 127 



296 128 



.XX 



• • XA X.X. m • 



1 
1. 



1. 
.1 



DCMMCSST 

DCMDUSE 
DCMNOHRD 
DCMOOMSS 
DCMOOSDS 



DCMIOUNQ 

DCMI0226 
DCMRPCUR 
DCMFRSCN 
DCMRDARM 
DCMW2250 
DCMINNOR 
DCMINERR 



Contains the current value of the RNUM parameter 
of the CONTROL S coinmand (numerical value) . 

Contains the current value of the RTME parameter 
of the CONTROL S command (numerical value) . 

The default value for SEG. 

The default value for RNUM. 

The default value for RTME. 

The ENTER mask. 

The CANCEL mask. 

The cursor mask. 

The light pen mask. 

The PFK mask. 

Screen control option flags. 

Delete verification (Y=l; N=0) . 
Automatic deletion (Y=l; N=0) . 
Default SEG specified. 
Roll mode specified. 
Reserved. 

Open/Close request. 

Close requested. 
Open requested. 
Reserved. 

Reserved. 

Current display status flags. 

Full screen. 

DNVIEWABLE MESSAGE written to screen- 
Messages are numbered. 
Messages numbered — HOLD option. 
Intervention requested deletion tried. 
Automatic deletion tried. 
Reserved. 

MCS Interface flags. 

Status Display Support. 
No hardcopy message written. 
Message stream entry. 
Status display entry. 
Reserved. 

Device I/O information flags. 

(226J3) RMI performed. 
(2260) Advance cursor to blanks. 
(2260) Put output in hold mode. 
(2250) Perform read after RMI. 
(2250) Device is a 2250. 
(2250^) Normal instruction line. 
(2250) Error instruction line. 
Reserved. 
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297 129 



298 12A 



299 12B 



1 
1. 



1.. 
1. 



1 
1. 



300 


12C 


1 


301 


12D 


1 


302 


12E 


1 


303 


12F 


1 

1 



1. 
.1 
..1 
...1 



..1 

...1 

— 1... 
1.. 

• ••• ••J.* 



.1 .. 

.. 1. 

.. .1 

• • « • ^ 



1.. . 
.1. . 
..1 . 
... 1 



DCMIOCMl I/O Communications byte 1. 

DCMDORMI Issue RMI. 

DCMSOUND Sound alarm. 

DCMWRWRN Write warning line. 

DCMWRMSG Write full message area. 

DCMWRPAR Write partial message area. 

DCMWRINS Write instruction line. 

DCMWRENT Write entry area. 

DCMINSC Insert cursor. 

DCMI0CM2 I/O Commuttiications byte 2. 

DCMBLENT Blank entry area. 

DCMBLWRL Blank left half of warning line. 

DCMBLWRR Blank right half of warning line. 

DCMINSSH Initialize and shift instruction line. 

DCMWINFD Write informational display. 

DCMERASE Perform erase. 

DCMIOCRD Perform read. 

DCMWRASY Write asynchronous error message to mid-screen. 

DCMI0CM3 I/O Communications byte 3. 

DCMOPRMI RMI after OPEN to unlock keyboard. 

DCMSSRG Suppress start regeneration. 

Reserved. 

DCMWRPFK Write PFK area. 

DCMPFKAT PFK attention. 

DCMRDPFK PFK area read. 

DCMACPFK Turn active PFK lights on. 

DCMLTPFK Turn all PFK lights on. 

DCMLINEN Line numbers to begin write. 

DCMCULNO Line in entry area to insert cursor. 

DCMPOSCU Position to insert cursor. 

DCMASYNC Asynchronous error retry flags. 

DCMASCAN Asynchronous error message on screen. 

DCMASDA Retry bit. 

DCMASIN Retry bit. 

DCMASBA Retry bit. 

DCMASLOG Log asynchronous error. 
Reserved- 



30a 130 



305 131 



1 
1. 



1., 
1, 



1. 
.1 

. .X 

...1 



1 
1. 



1.. 
.1. 
..1 



DCMCOMl Communications byte 1. 

DCMLPENT Enter by light pen or cursor. 

DCMIOPRD Read performed. 

DCMCOMRM RMI performed. 

DCMCONAU Perform automatic deletion- 

DCMCOMRD Perform regular deleteion. 

DCMCOMNM Number messages. 

Reserved. 

DCMCANCL Indicate CANCEL to Command routine. 

DCMC0M2 Communications byte 2. 

DCMCM2I Input to be processed. 

DCMSPLIT Message to be split. 

DCMCOMAR Accepted reply. 

DCMCLOSE Cleanup for close. 

DCMERPF Erase performed; close device. 

DCMCMIN5 Return to Interface 5 for blanking. 
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306 132 



307 133 



1. 

1 



.1. 
..1 



1. ., 
.1 .. 
.. 1. 



.X 

..1 



1. 
.1 



.1 
..1 



DCMBLNK 
DCMAE 

DCMC0M3 

DCMCDSP3 
DCMRTPFK 
DCM7LPFK 
DCMXINTl 
DCMOLDNV 
DCMPFKWR 

DCMCMIN7 

DCMCMSGl 

DCMMSGWT 
DCMUNMSG 
DCMCHOPT 
DCMELONG 
DCMWRCDL 
DCMDELNT 
DCMMNHRD 



Blanking required. 

Cleanup for asynchronous error. 

Conanunications byte 3. 

Display 3 work complete. 

Return to PFK routine. 

Verifying last command. 

Entry for Interface 1 routine. 

Out-of-line message caused UNVIEWABLE MESSAGE. 

Write PFK updates to library. 

Reserved. 

Return to Interface 7 for blanking. 

Message Module Communications byte 1. 

Move in MESSAGE WAITING. 

Move in UNVIEWABLE MESSAGE. 

Move in CHANGE OPTIONS. 

Move in ENTRY TOO LONG. 

Move in CON=N,DEL=y. 

Move in DEL UNCHANGED, NO TIMER. 

Move in NO HARDCOPY. 



308 13U 



1. .. 
.1 .. 
.. 1. 
.. .1 



DCMCMSG2 Message Module communications byte 2. 

DCMDLREQ Move in DELETION REQUESTED. 

DCMRQINC Move in REQUEST INCONSISTENT. 

DCMMSGCR Move in INVALID CURSOR OPERATION. 

DCMINVOP Move in INVALID OPERAND. 

DCMCILLP Move in ILLEGAL LIGHT PEN OPERATION. 

DCMDELRI Move in DELETE REQUEST INCONSISTENT. 

DCMASYRT Move in ASYNCHRONOUS ERROR RETRYABLE. 

DCMASYCD Move in ASYNCHRONOUS ERROR MAY BE RETRYABLE. 



309 135 



1 
1. 



1.. 
1. 



1. 
.1 



DCMCMSG3 Message Module Communications byte 3. 

DCMCNRLL Move in ROLL MODE. 

DCMCDLRl Move in NO DELETABLE MESSAGES. 

DCMCDLR2 Move in INVALID RANGE. 

DCMCDLR3 SEG equal to zero. 

DCMCDLR4 Display not on screen. 

DCMCDLR5 Invalid operand. 

DCMNHCIN Move NO HARDCOPY message to instruction line. 

DCMDTBSY COMMAND REJECTED — TASK BUSY. 



310 


136 


1 








1... 


• • • • 






.1.. 


• • • • 






..1. 


■ • • a 






...1 


• • • • 






• • • • 


xxxx 


311 


137 


1 








1... 


• • • • 






.1.. 


• • • • 






..1. 


• • • • 






• • • 3C 


xxxx 


312 


138 


1 




313 


139 


1 




314 


13A 


1 





DCMCMSG4 

DCMPFKNA 
DCMPFKND 
DCMPFKNO 
DCMPFKIP 



DCMSVC34 

DCMMYCMD 
DCMINVLD 
DCMTYPEl 



DCMIORTN 



DCMTEST 



Message Module communications byte U. 

Move in PFK NOT ALLOCATED. 
Move in PFK NOT DEFINED. 
Move in NO PFK ALLOCATION. 
Move in PFK IN PROCESS. 
Reserved. 

SVC 34 Communications byte. 

Command to be handled by this console. 

Invalid K command. 

K command is not routable. 

Reserved. 

Reserved. 

Indicates which I/O routine handles I/O for the 
console. 

Reserved for testing. 
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316 13C 



318 13E 



320 140 



322 142 



324 144 



326 146 



Device Dependent Section ; 
play device that the DCM 

Offset Bits and 
Dec Hex Byte Pattern 

328 148 Variable 



DCMBASRT Location in buffer for start of the channel pro- 
gram regeneration orders. 

DCMBAMI Location of first message line for use by the 
channel program. 

DCMBAPFK Location of the PFK display line in the buffer 
for use by the channel program. 

DCMBAINS Location of the instruction line in the buffer 
for use by the channel program. 

DCMBAENT Location of the entry area in the buffer for use 
by the channel program. 

DCMBAWRN Location of the warning line in the buffer for 
use by the channel program. 

The following areas vary in size according to the type of dis- 
is supporting. 



Field 
Name 



Field Description, Contents , Meaning 

Buffer Address Table: contains addresses of the 
buffers for the various display screen fields. 



Variable Variable 



Variable Variable 



Variable 



Variable 



Variable 



Variable 



Channel Program Area 
programs . 



work area for channel 



Screen Immage Buffer - contains a copy of the 
display screen. It is from this area that the 
screen is written and information of the screen 
is manipulated. 

DOM Identification Numbers Area - contains infor- 
mation pertaining to delete- operator- message 
messages. 

Screen Control Table - flags for each line in the 
screen image buffer. 



Byte 

1.. .. 

1. .. 

.1 .. 

.. 1. 



.1 
..1 



DCMMSGWR WTOR message display in-line. 

DCMMSGIN Message Display in-line. 

DCMMSGCN Message continued on next line. 

DCMMSGJK To write out-of-line display. 

DCMMSGAD Message can be deleted automatically. 

DCMMSGRD Request has specified this message be removed. 

DCMMSGIF Informational message displayed in-line. 

DCMMSGST End of table indicator - 



Variable 



Byte 1 
1... 
1. 



1. 
.1 
..1 
...1 



Variable 



DCMMSGAC Action message. 

DCMMSGC7 Descriptor code 7 message. 

DCMMSGDM DOM issued for this message. 

DCMMSGAR Message is an accepted reply. 

DCMMSGIR Intervention required message. 

DCMMSGCT Continuation line. 

DCMMSGPP Message issued by problem program. 

DCMMSGCL Control line of MLWTO. 

Secondary Screen Control Table 
of-line display area messages. 



Flags for out- 






DCMSECCL Control line of out-of-line display. 
DCMSECLL Label line of out-of-line display. 
DCMSECDL Data line of out-of-line display. 
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. 1 .... DCMSECBL This line is blanked. 

. . XX. . Reserved. 

. . ..1. DCMSECDD Line reserved for dynamic display. 

1 DCMSECST End of table indicator. 



MOLTIPROCESSING COMMDNICATIONS VECTOR TABLE (MPCVT) 

The MPCVT is part of the resident nucleus and begins at symbolic location lEAMPCVT. 
The address of the first location of the MPCVT is contained in the CVTMPCVT entry of the 
CVT and also in the MPCVTPTR field of the Prefixed Storage Area. 



Offset 
Dec Hex 



2 

<t 

8 

12 

16 

20 

24 

28 

32 



2 
H 
8 
C 
10 
14 

18 

IC 

20 



Bits and 
Byte Pattern 



1100 0001 
1100 0010 
0000 0000 



1111 1111 
0000 0000 

2 

4 

4 

4 

4 

4 



Field 
Name 

CVTAFFLK 



CVTSTPTR 

CVTWTTCB 

CVTTKRM 

CVTGOV 

CVTIOTIO 

CVTIOTCH 

CVTSTOR 

CVTVRYOF 



Field Description, Contents, Meaning 

CPU identity. 

CPU A. 
CPU B. 
Neither . 

Supervisor lock. 

Set. 
Not set. 

Reserved. 

Address of SHOLDTAP routine. 

Address of Dispatcher Wait Task. 

Address of Task Removal (TESTDSP) routine. 

Address of GOVRFLB table. 

Address of Multiprocessing Unit TIO routine in 
lOS. 

Address of Multiprocessing Channel TCH routine in 
lOS. 

Address of Notify Storage Inline routine 
(lEAMPSTR). 

Address of Deferred Vary Storage routine 
(IFSVRYOF) . 
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VARY QOEUE ELEMENT (VQE) 

The VQE describes the main storage area to be logically removed from a Model 65 Mtilti- 
processing system due to a VARY STORAGE offline command. The address of the Vary Queue 
Element is located in the GOVRFLB table. 

Field 

Name Field Description, Contents. Meaning 

Zero. 

Address of next VQE on vary gueue. 

Zero. 

Lower address of area specified in VARY conaaand. 

Zero. 

Length of area specified in VARY command. 

Zero. 

ECB posted by FREEPART. 



Offset 


Bits 


and 


Dec 


Hex 



Byte 


Pattern 





1 




1 


1 


3 




4 


H 


1 




5 


5 


3 




8 


8 


1 




9 


9 


3 




12 


C 


1 




13 


D 


3 





FAIL SOFT STORAGE ELEMENT MAP (FSSEMAP) 

The FSSEMAP is a 128-byte (1024 bits) field located at hex location 300 in a multi- 
processing system. Each 2K block of main storage is described by two bits which can have 
the following values ; 



Setting 


Indication 




00 


Normal-described by an 
or PQE 


FBQE 


01 


Reserved 




10 


Reserved 




11 


Logically removed from 


the 




system - not described 


by an 




FBQE or PQE 





Given a main storage address (X), the corresponding 2K block (b) is: 

X (disregard remainder). 

b = 

2048 

The number (n) of the first of the two bits which describes the 2K block is: n = 2*b. 
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UNIT CONTROL MODULE (UCM) BASE 



Offset 


Bits and 


Field 


Dec 


Hex 


Byte Pattern 


Name 


-8 


-8 


4 




-4 


-4 


4 










4 


UCMXECB 


4 


4 


4 


UCMAECB 


8 


8 


4 


UCMOECB 


12 


C 


4 


DCMDECB 


16 


10 


4 


UCMHECB 


20 


14 


4 


UCMLSTP 


24 


18 


4 


UCMWTOQ 


28 


IC 


4 


UCMRPYQ 


32 


20 


13 


UCMRPYI 


45 


2D 


1 


UCMRQLM 


46 


2E 


2 


UCMWQLM 


48 


30 


4 


UCMRQECB 


52 


34 


4 


UCMWQECB 


56 


38 


2 


OCMRQNR 


58 


3A 


2 


UCMWQNR 


60 


3C 


4 


UCMWQEND 


64 


40 


4 


UCMPXA 


68 


44 


1 


UCMMODE 






• ••• X**a 


UCMAMFA 






• ••• aXw* 


UCMOGCE 






• ••• aaX* 


UCMMCS 






0000 0000 


UCMFIX 


69 


45 


1 


UCMCORE 


70 


46 


1 


UCMMODEL 


71 


47 


1 


UCMINCR 


72 


48 


4 


UCMVEA 


76 


4C 


4 


UCMVEZ 


80 


50 


4 


UCMVEL 


84 


54 


56 


UCMSAVE3 



Field Description, Contents, Meaning 

Address of UCM extension prefix. 

Address of MCS prefix. 

External interruption ECB. 

Attention interruption ECB. 

WTO/R request ECB. 

DOM request ECB. 

RMS request ECB. 

Address of event indication list (UCMEIL) . 

Address of first WQE (system output queue). 

Address of first RQE (reply queue element). 

Reply ID assignment pattern (100 bit positions 
used) . 

ID assignment limit. 

WQE buffer limit. 

Reply request vraiting ECB. 

Buffer request waiting ECB. 

Current RQE count. 

Current WQE count. 

Address of last WQE, or zero. 

Address of communications task ECB (lEECVTCB). 

Mode flags. 

Accept VARY command with MSTCONS operand from any 

MCS secondary console. 

Only graphics consoles exist. 

MCS generated with system. 

MVT mode. 

WTO Purge routine switches. 

System model number. 

Used by Console Initialization routine for error 
handling. 

Address of first UCM entry. 

Size of UCM entry. 

Address of last UCM entry. 

Save area for ED2 (ref reshability) . 
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lUO 8C 6H 
20H CC 4 



UCMSAVE4 Save area for CRA (ref reshability) . 
UCMR9SV Save area for ED2 Cref reshability) , 



PCM EXTENSION PREFIX TO DNIT CONTROL MODULE (UCM) BASE 



Offset 


Bits 


and 


Field 


Dec Hex 


Byte 


Pattern 


Name 


-12 -12 


2 




UCM2WID 


-10 -10 


2 




UCM2RID 


-8 -8 


4 




UCM2PST 



Field Description, Contents, Meaning 
Terminal job ID of task for UCMWQECB. 
Terminal job ID of task for UCMRQECB. 
Address of POST validity checking. 



MULTIPLE CONSOLE SUPPORT PREFIX TO UNIT CONTROL MODULE (UCM) BASE 



Offset 


Bits 


and 


Field 


Dec 


Hex 


Byte 


Pattern 


Name 








4 




UCMMCENT 


H 


4 


72 




UCMSAVEO 


76 


4C 


4 




UCMDOME 


80 


50 


4 




UCMWTOX 


84 


54 


2 
Byte 





UCMFLGS 






X. .. 


• • • • 


UCMSYSA 






.1.. 


• • • • 


UCMSYSB 






..1. 


• • • • 


UCMSYSC 






...1 


• • • • 


UCMSYSD 






• • • • 


1... 


UCMSYSE 






• • • • 


.1.. 


UCMSYSF 






• • • • 


..1. 


UCMSYSG 






• • • • 


...1 


UCMSYSH 






Byte 


1 








1... 


• • • • 


UCMSYSI 






.1.. 


• • • • 


UCMSYSJ 






..1. 


« • • • 


UCMSYSK 






...1 


• • • • 


UCMSYSL 






• • • • 


1... 


UCMSYSM 






• « • • 


.1.. 


UCMSYSN 






• • • • 


..1. 


UCMSYSO 






.... 


. . .X 




86 


56 


2 




UCMOWTOR 


88 


58 


4 




UCMCMID 


92 


5C 


4 




UCMHCUCM 



Field Description, Contents, Meaning 
Address of Master Console UCM entry. 
Resident and communications save area. 
Address of first DOM element. 
Address of WTO/R Exit routine (lEECVXIT), 
System control flags. 



Reserved. 

Hard copy support required. 
Commands to hard copy. 
Console switch for master. 
No consoles exist. 
Graphic consoles exist. 
Hard copy device SYSLOG. 
Timer present and operative. 



WQE housekeeping needed. 

Hard copy to be written. 

New console composite. 

OPEN being issued to ring console bell. 

Failing console composite. 

Model 85 Operator Console with CRT Display. 

Dummy attention by WTL. 

Reserved. 

Default values for old WTOR macros. 

Current message identification number. 

Address of hard copy UCM entry, or zero. 
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96 


60 


1 


97 


61 


3 


100 


64 


2 


102 


66 


2 


104 


68 


24 


128 


80 


4 


132 


84 


4 


136 


88 


4 


140 


8C 


4 



144 



90 



148 


94 


4 


152 


98 


4 


156 


9C 


1 

- . XX xxxx 


157 


9D 


3 


160 


AO 


4 


164 


A4 


4 



UCMXCT 

UCMUEXIT 

UCMHRDRT 

UCMXSA 

UCMQRTN 

UCMRUTCK 

UCMDOMRT 

UCMTPPTR 

UCMNPECB 

UCMLOGAD 

UCMDTINT 

UCMSDSl 

UCMSDSIA 
UCMSDSIB 



UCM2EXT 
UCMMCENT 



External request count. 

Address of user exit data, or zero. 

Hard copy routing code assignments. 

Reserved. 

Parameter list area for SVC 72. 

Address of ENQ entry point (lEECMENQ) . 

Route checking field. 

Address of DOM routine entry point. 

Address of save area for 2740 device support pro- 
cessor, or zero. 

NIP ECB (posted when NIP routine's hard copy can 
be written) . 

Address of MCS Log. 

Dynamic display time interval. 

Status display flags. 

STCMDS to hard copy. 
INCMDS to hard copy. 
Reserved. 

Reserved. 

Address of UCM extension. 

Address of MCS prefix. 
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UCM ENTRY INDIVIDUAL DEVICE MAP 



Offset 
Dec Hex 



Bits and 
Byte Pattern 



Field 
Name 

UCMECB 



4 


4 


4 




OCMSRB 


8 


8 


4 




UCMDCB 


12 


C 


4 




UCMUCB 


16 


10 


8 




UCMNAME 


2H 


18 


1 




UCMSTS 






1..- 
.1.. 
..1. 
...1 


• • • • 

1... 
.1.. 


UCMAF 
UCMPF 
UCMBF 
UCMCF 
UCMTA 
UCMTB 






• • • • 

• • • • 


. .X. 

...1 


UCMTC 


25 


19 


1 




UCMATR 






1... 
.1.. 
..1. 
...1 

« « • • 


• • • « 

• • • • 

• • • a 

1... 
.1.. 


UCMOF 
UCMIF 
UCMXF 
UCMUF 
UCMLF 
UCMAT04 






• « • • 


. .XX 




26 


lA 


1 




UCMID 


27 


IB 


1 






28 


IC 


4 




UCMXB 


32 


20 


2 




UCMRTCD 


34 


22 


2 






36 


24 


2 




HCMODTQ 


40 


28 


2 




UCMAOTH 






Byte 
1... 
.1.. 
..1. 




• • • • 

• • • • 

• • • • 


UCMAUTHl 
UCMAUTH2 
UCMAnTH3 






. ..X 


xxxx 








Byte 


1 




42 


2A 


2 




UCMDISP 






Byte 
1... 
.1.. 
..1. 
...1 

• • « • 

• • • • 




• • • « 

• • • • 

• • • • 

• • • • 

1... 
.1.. 


UCMDISPA 
UCMDISPB 
UCMDISPC 
UCMDISPD 
UCMDISPE 
UCMDISPF 



Field Description. Contents, Meaning 

I/O completion ECB, or address of I/O completion 
ECB for 2740. 

Address of resident processor module. 

Address of DCB. 

Address of UCB. 

Processing module name. 

Status flags. 

Attention pending. 

Output pending. 

Device busy. 

Close pending. 

Open pending. 

Dequeue appropriate output queue entries. 

Reserved. 

Working on in-line status display. 

Attribute flags. 

WTO support. 

Attention support. 

External interruption support. 

Device active. 

Load flag. 

Device status to change. 

Reserved. 

Unique entry ID. 

Reserved. 

Address of DCM (Graphics), or zero. 

Routing codes assigned to this console - 

Reserved. 

Address of output queue. 

Command code authorization. 

Command group 1 (System) . 

Command group 2 (I/O). 

Command group 3 (CONS) . 
Reserved. 

Reserved . 

Disposition flags. 



Master console. 

Hard copy device/ console. 

Graphics . 

Output only. 

Console has full I/O capability. 

Console is in message stream only. 
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• • • • 


..1. 






• • • • 


...1 






Byte 


1 


nn 


2C 


4 




48 


30 


4 




52 


34 


4 




56 


38 


4 




60 


3C 


2 








Byte 









1... 


• • « • 






.1.. 


• • • • 






..1. 


• • • • 






. . .X 


* • • • 






a • • • 


1... 






• • « • 


.1.. 






• • • • 


. .X. 






• • • • 


. ..x 






Byte 


1 


62 


3D 


1 




63 


3E 


1 








1... 


• • • • 






.1.. 


• • • ■ 






..1. 


• • « • 






...1 


• • • • 






• • • « 


1... 






• • • • 


.1.. 






• • • . 


..1. 






• * • • 


• « • X 


6H 


40 


4 




68 


44 


1 








1... 








.1.. 


• • • • 






..1. 


• • • • 






...1 


• • • • 






• • • • 


1... 






• • • • 


.1.. 






• • • • 


..1. 






• « • • 


. . .X 



69 



45 



UCMDISPG Console is in status display only. 

UCMDISPH MCS. 

Reserved. 

UCMALTEN Address of alternate input UCM entry. 

UCMOAOEN Address of alternate output. 

UCMWLAST Address of last WQE entry serviced in output 
queue. 

UCMCOMPC Address of other device if console is composite. 

UCMMSG Message flags. 

UCMMSGA Monitor JOBNAMES requested. 

UCMMSGB Monitor STATUS requested. 

UCMMSGC Monitor ACTIVE. 

UCMMSGD Reserved. 

UCMMSGE SHOW requested. 

UCMMSGF Monitor SESS requested. 

UCMMSGG Reserved. 

UCMMSGH Reserved. 

Reserved. 

UCMXOR Zero. 

UCMDEVC Device control flags. 

UCMDEVA Full screen on graphics console. 

UCMDEVB Prepare command issued. 

UCMDEVCC Tested for console switch. 

UCMDEVD DOM issued. 

DCMDEVE 1/0 complete. 

DCMDEVF Modified DCM for DOM. 

DCMDEVG Halt I/O issued on 2740. 

DCMDEVH Reserved. 

UCMMLAST Address of last minor WQE serviced. 

UCMSDS5 Status display flags. 

UCMSDS5A MLWTO line: need to keep writing. 

UCMSDS5B In-line output pending. 

UCMSDS5C Out-of-line output pending. 

UCMSDS5D Transient DCM blocked. 

UCMSDS5E Transient DCM locked. 

UCMSDS5F For CRT, UCMWLAST valid. 

UCMSDS5G I/O hardware in output only. 

UCMSDS5H Reserved. 

UCMRCT Address of message routing control table. 
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UCM MESSAGE TEXT AND EVENT INDICATION LIST (EIL) AREAS 

The following fields are used only if a user exit was specified. 

Field Description, Contents, Meaning 

Message text (128 characters) - 

Routing codes. 

Messa,ge descriptor codes. 

Save area for lEECMWSV interface. 

nt indication list. 

Length in doublewords. 

Last assigned reply ID. 

Route count. 

Reserved. 

Address of 2K NIP message buffer. 

Address of external ECB. 

Address of attention ECB. 

Address of WTO/R ECB. 

Address of DOM ECB. 

Address of RMS ECB. 

List of all I/O ECB addresses. One word for each 
console device specified at system generation, 
with a minimum of 2 entries. The list is vari- 
able at SYSGEN only. Last entry has a high-order 
byte = X'80'. (Maximum of 128 bytes.) 

The following field is only present when a 2740 is used as the system console. 

Variable 72 OCMTPSAV Save area for 2740 Device Support Processor. 



Offset 


Bits 


and 




Field 


Dec 


Hex 


Byte 


Pattern 


Name 








128 






UCMMSTXT 


128 


80 


4 






UCMROOTC 


132 


84 


4 






UCMDESCD 


136 


88 


64 






UCMXTSAV 


The 


following fields 


constitute the ^ 








1 






OCMEIL 


1 


1 


1 






UCMRPYL 


2 


2 


1 






UCMRTCT 


3 


3 


1 








H 


4 


4 








8 


8 


4 








12 


C 


4 








16 


10 


4 








20 


14 


4 








24 


18 


4 








28 


IC 


Varii 


able 
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WRITE QUEUE ELEMENT (WQE) FORMAT FOR MULTIPLE CONSOLE SUPPORT (SINGLE-LINE WTO) 



The Write Queue Element (WQE) is a control block representing a message to be written 
to an operator's console. There are three forms of the WQE: the WQE (representing a 
single-line write-to-operator (WTO) message), the Major WQE (representing the first line 
of a multiple-line WTO message) , and the Minor WQE (representing one or more lines fol- 
lowing the first line of a multiple-line WTO message). 



Field Description, Contents. Meaning 

WQE use count. 

Address of next WQE. 

Message length. 

Message text (maximum of 128 bytes). 

Disposition flags. 

Purge. 

Queue for hard copy. 

RQE exists for this WQE. 

Queued for hard copy. 

WQE created for WTOR. 

Reserved. 

Time sharing user ID for swapped-out task. 

Buffer flags. 

Buffer is free. 

Buffer is in use. 

Buffer obtained dynamically. 

Buffer has been serviced. 

Reserved. 

Reserved for rollout/rollin. 

Routed WQE count. 

24-bit ID sequence number. 

MCS flags. 



Routing or descriptor codes exist. 

UCM entry identifier passed in register 0. 

Command response (includes hard copy). 

WQE WQEMSGTP field to be used for message 

identification. 

Accepted reply to a WTOR. 

Broadcast to all active consoles. 

Queue for hard copy only. 

Queue to UCM entry passed in register 0- 



Time stamp exists in message text. 
Bypass hard copy queuing. 
Reserved for DOM function. 
Reserved for Graphics. 
Reserved. 

Message flags. 
Monitor JOBNAMES. 



Offset 
Dec Hex 


Bits 
Byte 


and 
Pattern 


Field 
Name 








1 




WQEUSE 


1 


1 


3 




WQELKPTR 


4 


4 


4 




WQENBR 


8 


8 


Variable 


WQETXT 


136 


88 


1 




WQEXA 






1... 
.1.. 
..1. 
...I 

• • ■ • 


• • • ■ 

• • • • 

• • • • 

• • • • 

1... 

.XXX 


WQEPURGE 

WQEQFHC 

WQERQE 

WQEQDFHC 

WQEXWTOR 


137 


89 


2 




WQETJIDl 


139 


8B 


1 




WQEAVAIL 






1... 
.1.. 
...1 

• • • • 

. .X. 


• • • • 

• ■ • • 

• • • • 

1... 

.XXX 


RQEBUFA 
RQEBUFB 
RQEBUFD 
RQEBUFE 


140 


8C 


4 




WQEXB 


144 


90 


1 




WQERTCT 


145 


91 


3 




WQESEQN 


148 


94 


2 




WQEMCSF 






Byte 
1... 
.1.. 
..1. 
...1 




• • • • 

• • • • 

• • « • 

• « • • 


WQEMCSA 
WQEMCSB 
WQEMCSC 
WQEMCSD 






• • • • 

• * • • 


1... 
.1.. 
..1. 
...1 


WQEMCSE 
WQEMCSF 
WQEMCSG 
WQEMCSH 






Byte 
1... 

• • • • 

• • • • 

• • • • 

.XXX 


1 

• • • • 

.1.. 
..1. 
...1 

3C • • • 


WQEMCSI 
WQEMCSN 
WQEMCSO 
WQEMCSP 


150 


96 


2 




WQEMSGTP 






Byte 
1... 




• « • • 


WQEMSGTA 



354 







•••• X*** 






1. . 






. . XX . . XX 






Byte 1 


152 


98 


2 


154 


9A 


2 


156 


9C 


1 


157 


9D 


1 


158 


9E 


2 


160 


AO 


2 


162 


A2 


2 


164 


AH 


4 



WQEMSGTB 
WQEMSGTE 
WQEMSGTF 



WQEROOT 

WQECMID 
WQEPKE 

WQEDESCD 

WQETIME 



Monitor STATUS. 
Display SHOW. 
Monitor SESS. 
Reserved. 

Reserved. 

Routing codes. 

Reserved. 

Unique UCM entry ID. 

TCB key of WTO issuer. 

Reserved. 

Descriptor codes. 

Reserved. 

Timer element. 
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MAJOR WRITE QUEUE ELEMENT CNON-MCS) 



Offset 
Dec Hex 





1 
4 



6 

8 

80 

120 

122 



124 

128 
132 

136 




1 
H 



6 

8 

50 

78 

7A 



7C 

80 
84 

88 



137 89 
139 8B 



Bits and 
Byte Pattern 

1 

3 

1 

1.. . 
1. . 
.1 . 
.. 1 

1 
.1 
X. . 



2 
72 

40 
2 
2 
Byte 

••Xa ••«• 

• • • • AiJvJCa 

Byte 1 
4 

4 
4 

1 

1.. , 

.1. , 
..1 . 

• • • J 

• • • • JuCX 



2 
1 



1.. . 
-1. . 
..1 . 

... 1 



.XXX 



140 8C 



Field 

Name Field Description, Contents. Meaning 

WMJUC Use count for WQE. 

WMJNXT Address of next WQE. 

WMJMLW MLWTO flags. 

WMJMIiWA Message displayed. 

WMJMLWB Major. 

WMJMLWC Minor. 

WMJMLWD Chain altered. 

WMJMLWE WTL issued. 

WMJMLWG Chain to be serviced. 

WMJMLWH Minor queued has no text. 
Reserved. 

WMJAREA Identifier of the display area to which the mes- 
sage is to be routed. 

WMJTXTL Text length. 

WMJTXT Text. 

WMJRES Reserved. 

WMJSER Previous line types for error checking. 

WMJLTYP Line type of message in text field. 



WMJLTYPA Control line- 
WMJLTYPB Label line. 
WMJLTYPC Data line. 
WMJLTYPD End indicator. 
Reserved. 

Reserved. 

WMJNXTM Address of first minor WQE associated with this 
major WQE. 

WMJTCB Address of the TCB that issued the MLWTO. 

WMJMSGN Message identification number assigned to the 
MLWTO. 

WMJDISP Disposition flags. 

WMJDISPA Purge this WQE- 
WMJDISPB Queue for hard copy. 
WMJDISPC This WQE has an RQE. 
WMJDISPD Queued for hard copy. 
WMJDISPE WQE is for a WTOR. 
Reserved. 

WMJTJID TSO user identifier. 

WMJBUF Buffer status flags. 

WMJBUFA Buffer space available. 
WMJBUFB Buffer space in use. 
WMJBUFC Reserved. 

WMJBUFD Buffer space acquired by GETMAIN. 
WMJBUFE WQE serviced. 
Reserved. 

WMJRORI Information pertaining to rollout/rollin. 
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MAJOR WRITE QUEOE ELEMENT (MCS) 



Offset 
Dec Hex 





1 
H 



Bits and 
Byte Pattern 

1 

3 

1 



1... 
1.. 
1. 



1- 
.1 



6 


6 


2 




8 


8 


6 




in 


E 


1 




15 


F 


4 




19 


13 


1 




20 


in 


72 




92 


5C 


18 




110 


6E 


2 




112 


70 


8 




120 


78 


2 




122 


7A 


2 








Byte 









1... 
.1.. 


« • • ■ 






-.1. 


• • • « 






...1 


.... 






• • • • 


xxxx 






Byte 


1 


124 


7C 


4 




128 


80 


4 




132 


84 


4 




136 


88 


1 








1... 


• • • ■ 






.1.. 
. .1. 


• • • • 






...1 


• « • • 



Field 

Name Field Description, Contents, Meaning 

WMJMUC WQE use count. 

WMJMNXT Address of next WQE. 

WMJMMLW MLWTO flags. 

WMJMMLWA Entire first minor available. 

WMJMMLWB Major. 

WMJMMLWC Minor. 

WMJMMLWD Chain altered. 

WMJMMLWE WTL issued. 

WMJMMLWF (For lEECMWSV) start at top of chain. 

WMJMMLWG Chain to be serviced. 

WMJMMLWH Minor queued has no text. 

WMJMAREA Identifier of the display area to which the dis- 
play is to be routed. 

WMJMTXTL Text length. 

WMJMTS Time stamp for hard copy messages. 

WMJMPAD Reserved. 

WMJMRR Routing codes for hard copy messages. 

WMJMPADl Break for hard copy text. 

WMJMTXT Text of the message to be passed to the operator. 

WMJMRESA Reserved. 

WMJMSER Previous line types for error checlcing. 

WMJMCONS Framing indicators (for display consoles). 

WMJMRESB Reserved. 

WMJMLTYP Line type of line in text field. 

WMJMLTYPA Control line. 

WMJMLTYPB Label line. 

WMJMLTYPC Data line. 

WMJMLTYPD End indicator. 
Reserved. 

Reserved. 

WMJMMIN Address of first minor WQE chained to the major 

WQE. 

WMJMTCB Address of the TCB that issued the MLWTO. 

WMJMMSGN Message number assigned to the MLWTO. 

WMJMDSP Disposition flags. 

WMJMDSPA Purge the WQE. 

WMJMDSPB Queue for hard copy. 

WMJMDSPC This WQE has an RQE. 

WMJMDSPD Queued for hard copy. 
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1... 

.XXX 



137 
139 



150 



89 

8B 



149 95 



96 



1.. . 
.1. . 
..1 . 
... 1 



.XXX 



140 


8C 


4 


1U4 


90 


1 


145 


91 


3 


148 


94 


1 
1 



1. .. 
.1 .. 
.. 1. 



.1 

..1 



1.. 
.1. 
..1 



1 
1. 



1.. . 
1. . 
.1 . 

.. 1 



.1 

. .XX 



151 


97 


1 


152 


98 


4 


156 


9C 


1 


157 


9D 


1 


158 


9E 


2 


160 


AO 


4 


164 


A4 


4 



WMJMDSPE WQE is for WTOR. 
Reserved. 

WMJMTJID TSO user identifier. 

WMJMBUF Status flags of the buffer used by the WQE. 

WMJMBUFA Buffer Space available. 

WMJMBOFB Buffer in use. 

WMJMBUFC Reserved. 

WMJMBUFD Buffer acquired by GETMAIN. 

WMJMBUFE WQE serviced. 
Reserved. 

WMJMRORI Information pertaining to rollout/rollin. 

WMJMRTCT Routed WQE count. 

WMJMSEQ Sequence number assigned to message. 

WMJMCSl MCS flags. 

WMJMCSIA Routing or descriptor codes exist. 

WMJMCSIB UCM entry ID passed in register 0. 

WMJMCSIC Command response (hard copy). 

WMJMCSID WMJMMTl field indicates message type. 

WMJMCSIE Accepted reply to WTOR. 

WMJMCSIF Queue to all active consoles. 

WMJMCSIG Queue to hard copy only. 

WMJMCSIH Queue to UCM entiry passed in register 0. 

WMJMCS2 MCS flags. 

WMJMCS2A Time stamp in message text. 

WMJMCS2B WQE represents a multiple-line message. 

WMJMCS2F Bypass hard copy queuing. 

WMJMCS2G Reserved for DOM. 

WMJMCS2H Reserved for graphics. 
Reserved. 

WMJMMTl Types of messages the WQE represents. 

WMJMMTIA Display JOBNAMES. 

WMJMMTIB Display STATUS. 

WMJMMTIC Monitor ACTIVE. 

WMJMMTl D Reserved. 

WMJMTTIE SHOW requested. 

WMJMTTIF Monitor SESS. 
Reserved. 

WMJMMT2 Reserved. 

WMJMRTC Routing codes assigned to message. 

WMJMUID UCM entry ID. 

WMJMTID TCB key of the task that issued the WTO/R. 

WMJMRESC Reserved. 

WMJMDEC Descriptor codes assigned to message. 

WMJMTIM Timer element. 
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MINOR WRITE QUEUE ELEMENT (NOH-MCS) 



Offset 
Dec Hex 



Bit.s and 
Byte Pattern 



1 
4 



1 
H 



137 89 
139 8B 



3 

1 



1.. 
1. 
.1 







Byte 









1... 


« « • • 






.1.. 


« • « • 






..1. 


• • • • 






...1 


• « • • 






• • • • 


xxxx 






Byte 


1 


7 


7 


1 




8 


8 


4 




12 


C 


72 




84 


54 


52 




136 


88 


1 





1... 
1.. 
.1. 
..1 



2 

1 



1... 


• • • • 


.1.. 


* • • • 


..1. 


■ • • • 


...1 


• • • « 


• • • • 


1... 


• • • • 


.XXX 



Field 

Name 

WMNOC 



140 



86 



WMNEXT 
WMNMIM 



WMNMLHA 
WMNMLWB 
WMNMLWC 
WMNMLWD 
WMNMLWE 
WMNMLWG 
WMNMLWH 



WMNLT 



WMNLTA 
WMNLTB 
WMNLTC 
WMNLTD 



WMNTXL 

WMNHCT 

WMNTXT 

WMNRESA 

WMNDISP 

WMNDISPA 
WMNDISPB 
WMNDISPC 
WMNDISPD 
WMNDISPE 

WMNTJID 
WMNBUF 



WMNBUFA 
WMNBUFB 
WMNBUFC 
WMNBUFD 
WMNBUFE 



WMNRORI 



Field Description, Contents. Meaning 

Use count for the minor WQE. This use count is 
set equal to the use count of the major WQE when 
the MLWTO is queued. As each console finishes 
with the line represented by the minor WQE, the 
use count is decremented by 1. When the use 
count equals zero, the WQE is ready to be removed 
from the system. 

Address of the next minor WQE. 

Flags pertaining to the message represented by 
the minor WQE. 

Message displayed. 

Major. 

Minor. 

Chain altered. 

WTL issued. 

Chain to be serviced. 

GETMAIN issued for minor. 

Reserved. 

Flags indicating the line type of the text field. 



Control line. 
Label line. 
Data line. 
End indicator. 
Reserved. 

Reserved. 

Length of message in text field. 

Hard copy identifier. 

Message to be passed to operator. 

Reserved. 

Disposition flags. 

Purge this queue. 
Queue for hard copy. 
This WQE has an RQE. 
Queued for hard copy. 
This WQE is for a WTOR. 
Reserved. 

TSO user identifier. 

Flags indicating the status of the buffer used by 
the WQE. 

Buffer available. 

Buffer in use. 

Reserved. 

Buffer acquired by GETMAIN. 

WQE serviced. 

Reserved. 

Information pertaining to rollout/roll in. 
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MINOR WRITE QUEUE ELEMBMT (MCS) 



Offset 
Dec Hex 





1 





1 



89 59 



91 5B 

92 5C 
96 60 



Bits and 
Byte Pattern 

1 

3 







• J.. • 

..1. 


• • • • 

• • • ■ 






...1 


• • • • 






• « • • 


1... 






• « • • 


..1. 






• • • • 


...1 






X. . . 


• X • • 


5 


5 


2 








Byte 









1 


• • • • 






.1.. 
..1. 


• • • • 






...1 


xxxx 






Byte 


1 


7 


7 


1 




8 


8 


H 




12 


C 


72 




84 


5H 


1 




85 


55 


3 




88 


58 


1 





X 

2 
Byte 

• • • • XaXX 

Byte 1 

1 

H 

72 



Field 

Name Field Description. Contents, Meaning 

WMNMUCl Use count for the message in the Text 1 field. 

WMNMNXl Address of the second half of the WQE (address of 
WMNMUC2) . 

WMNMMLl MLWTO flags for the message in the Text 1 field. 

WMNMMLIB Major. 

WMNMMLIC Minor . 

WMNMMLID Chain altered. 

WMNMMLIE WTL issued. 

WMNMMLIG Chain to be serviced. 

WMNMMLIH GETMAIN issued for minor. 
Reserved. 

WMNMLTl Line type of message in the Text 1 field- 

WMNMLTIA Control line. 
WMNMLTIB Label line. 
WMNMLTIC Data line. 
WMNMLTID End indicator. 
Reserved. 

Reserved. 

WMNMTLl Length of message in the Text 1 field. 

WMNMHCTl Hard copy ID for the message in the Text 1 field. 

WMNMTXTl Text of the first message passed to the operator 
by this WQE. 

WMNMUC2 Use count for the message in the Text 2 field. 

WMNMNX2 Address of the next minor WQE. 

WMNMML2 MLWTO flags for the message in the Text 2 field. 

WMNMML2B Major. 

WMNMML2C Minor . 

WMNMML2D Chain altered. 

WMNMML2E WTL issued. 

WMNMML2G Chain to be serviced. 

WMNMML2H GETMAIN issued for minor. 
Reserved. 

WMNMLT2 Line type of message in the Text 2 field. 

WMNMLT2A Control line. 
WMNMLT2B Label line. 
WMNMLT2C Data line. 
WMNMLT2D End indicator. 
Reserved. 

Reserved. 

WMNMTL2 Length of message in the Text 2 field. 

WMNHCT2 Hard copy ID for the message in the Text 2 field. 

WMNMTXT2 Text of the second message passed to the operator 
by this WQE. 
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WTO/R MACRO EXPANSION 



Offset 


Bits 


and 


Field 


Dec 


Hex 


Byte 


Pattern 


Name 


wroR 


Prefix 








-8 


-8 


1 






-7 


-7 


3 






-4 


-4 


4 












1 






1 


1 


1 






2 


2 


2 

Byte 
1... 








,1 .. 
.. 1. 
.. .1 
.. -.1 



0000 0000 



Byte 1 







.XXX 


jCa • • 


4 


4 


Variable 


n 


n 


2 




n 


n 


2 




n 


n 


1 








1... 


• • • • 






-1.- 


• • « • 






• • « • 


1... 






• • • « 


.1.. 






. .XX 


. .XX 


n 


n 


1 




n 


n 


2 





Field Description, Contents. Meaning 

Length of reply. 

Address of requestor's reply buffer. 

Address of requestor's reply ECB. 

Zero. 

Output message length + 4. 

MCS flags. 



Routing and descriptor fields exist. (New WTOR/R 

Expansion. ) 

UCM entry identification passed in register 0. 

Command response. 

Message Type Flags field exists. 

This WTO is a reply to a WTOR. 

Broadcast to all active consoles. 

Queue for hard copy only. 

Queue to UCM entry passed in register 0. 

No routing or descriptor fields exist. 



Time stamp exists in message text. 

Bypass hard copy queuing (protect key zero users 

only) . 

Reserved for DOM function. 

Reserved for graphics. 

Reserved. 

Message ID and message text area (maximum of 128 
bytes) . 

16 -bit descriptor code. 

16-bit routing code. 

Message Type Flags. 

Monitor JOBNAMES- 
Monitor STATUS. 
Display SHOW. 
Monitor SESS. 
Reserved. 

Reserved. 

SVC 35. 
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MULTIPm-LINE WTO MACRO EXPANSION 



Variable 



Offset 


Bits 


and 


Field 


Dec Hex 


Byte 


Pattern 


Name 





1 




WTOMKl 


1 1 


2 




WTOLNTl 


2 2 


2 




WTOMCSF 




Byte 









1... 


to « • • 






.1.. 


« • • • 






..1. 


• • • • 






...1 


• • « • 






• • • • 


1... 






• • • • 


.1.. 






• • « • 


..1. 






• « ■ • 


...1 






Byte 


1 






1... 
.1.. 


• • • • 






• • • ■ 


.1.'. 






• • « • 


..1. 






• • ■ • 


...1 






. .XX 


3C« • • 




4 4 


Variable 


WTOTXTl 


Variable 


2 




WTODESC 




Byte 









1... 


• « • • 






.1.. 


• • • • 






..1. 


• • • • 






...1 


• « • • 






• • • • 


1... 






• . • • 


.1.. 






.... 


..1. 





Field Description, Contents, Meaning 



It signifies the 






Byte 


1 




1... 


• • • • 




.XXX 


xxxx 




2 




WTOROUT 


Byte 







1... 


• • ■ • 




.1.. 


• * • • 




..1. 


• • « • 




...1 


• • « • 




• « • •- 


1... 




• • • • 


.1.. 




• • • • 


..1. 




• • • • 


...1 




Byte 


1 




1 


« • • • 




.1». 


• • • • 





One-byte flag set to zeros, 
start of a new text field. 

Length of Text 1*4. 

MCS flags. 



Route and descriptor fields exist. 

OCM entry identification passed in register 0. 

Conraiand response. 

Message type flag field exists. 

This WTO represents a reply to a WTOR. 

Broadcast to all active consoles. 

Queue for hard copy only. 

No route or descriptor code field exists. 



Time stamp exists in message text. 

Multiple-line WTO. 

Bypass hard copy queuing (protect key zero users 

only) . 

Reserved for DOM function. 

Reserved for graphics. 

Reserved. 

First line of WTO text. 

Descriptor codes. 



System failure - another IPL is required. 
Immediate operator action is required. 
Eventual action required. 

System status is indicated by the message. 
Immediate command response - for error and non- 
error messages that are written as a result of an 
operator or system command. 
Job status indicated by the message. 
Application program/processor - for messages 
issued by a problem program and processors 
executed as problem programs. 
Operator request for status information. 



Out-of-line message. 
Reserved. 

Routing codes. 



Master console. 

Master console informational. 

Tape pool console. 

Direct access pool console. 

Tape library pool console. 

Disk library pool console. 

Unit record pool console. 

Teleprocessing control. 



System security. 

System error /maintenance. 
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• • • X 


« • • X 






• •- • • 


XXX. 




Variable 


2 




WTOMSGT 




Byte 
1... 
.1.. 
..1. 

• • • • 

• « • • 




• • • • 

• • • • 

• • • • 

.1.. 
..1. 






. ..X 


X. .X 






Byte 


1 




Variable 


2 




WTOLTl 


Variable 


1 




WTOAID 


Variable 


1 




WTOLCT 


Variable 


1 




WT0MK2 


Variable 


1 




WT0LNT2 


Variable 


2 




WT0LT2 


Variable 


Variable 


WT0TXT2 


Variable 


1 




WT0MK3 


Variable 


1 




WTOLNT3 


Variable 


2 




WTOLT3 


Variable 


Variable 


WTOTXT3 


Each subsequent text field 


is preceeded 



Programmer information console. 

Reserved. 

User routing codes. 

Message type flags. 



Display JOBNAMES. 
Display STATUS. 
Monitor ACTIVE. 
Display SHOW. 
Monitor SESS. 
Reserved. 

Reserved. 

Line type of Text 1. 

Area identifier for routing of the out-of-line 
status display represented by the multiple-line 

WTO. 

Number of lines in list. 

Next line marker. 

Length of Text 2 * H. 

Line type of Text 2. 

Second line of WTO text. 

Next line marker. 

Length of Text 3+4. 

Line type of Text 3. 

Third line of WTO text. 

by four bytes of information. 
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MACHINE CHECK RECORD FOR SERO AND SERl 



SERO and SERl produce two types of record entries corresponding to the two types of 
errors processed: machine-check and channel errors. Record size varies with the type of 
record and the machine model. 



Offset 
Dec Hex 



Bits and 
Byte Pattern 



J\,XjiJ^ « • • • 

xxxx . . 1 . 

xxxx 1 . . . 

xxxx 1 . . 1 

xxxx 1.1. 

xxxx 1.11 



• • « X. XjCXX 

. .Ix xxxx 

Bits 3-7 
0-lF 



Byte 

1.. 

0.. 

.1. 

..1 



. XXX 



Byte 1 

1. .. 
.1 .. 
.. 1. 







Bytes 2-3 


6 


6 


1 

xxxx .... 
.... xxxx 


7 


7 


1 


8 


8 


u 


12 


C 


n 


16 


10 


1 


17 


11 


3 


20 


in 


2 



Field 
Name 

CLASRC 



SYSREL 



SWITCHES 



RCDCNT 



DATE 
TIME 

CPUSER 
CPUID 



Field Description, Contents. Meaning 



Machine check record 


MCH. 




Converted 


MCH. 


SERl. 




SERO. 




Converted 


SERl. 


Converted 


SERO. 


OS. 




DOS. 





Release level 0-31. 



More records follow. 
Last record. 
Time-of-day clock. 
Extended control mode. 
Time macro used (HHMMSS) 
Reserved. 



Short form of record. 

Record incomplete. 

System terminated. 

First record of two record recording. 

Channel record included. 

Portion of data overlayed. 

External machine check. 

Reserved. 

Reserved. 



Sequence number of a physical record. 

Total number of physical records in this logical 

record. 

Reserved - 

The system date the record was made. 

The system time the record was made. 

Reserved. 

CPU serial number (System/370 only). 

CPU identifier. 
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22 16 



2a 18 8 



MCELLNG Maximum machine check extended log length 
(System/370 only). 

PROGID The module name of the program being processed 
and/or requesting service at the time of the 
error. 



32 20 



JOBID The name assigned to the job being executed at 
the time of the failure. 



HO 


28 


8 


PSW 


48 


30 


Variable 


LOGOUT 


aric 


ible 


Variable 


DAMAGE 



The machine check old PSW. 

Register contents and hardware logout informa- 
tion. Logout size and format is model dependent. 

Recovery Mcinagement Support's assessment of 
damage to the system. 
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STORAGE OTILIZATION BLOCK (SOB) 



The Storage utilization block (SUB) contains information pertaining to graphics con- 
soles that have been designated system operator's consoles. The SOB also contains RMS 
and SER channel programs used in systan recovery procedures. 



Field Description, Contents. Meaning 

Status flags of the I/O routine. 

I/O routine in use- 
Read in process. 
Write in process. 
Expecting control record. 
PFK write in process. 

Routing flags. 

Exit to Processor 1 routine. 
Initialize SUB on first entry. 
Write PFK updates. 
PFK keys are supported. 

Number of transient consoles. 



Offset 


Bits 


and 


Field 


Dec Hex 


Byte 


Pattern 


Name 





1 




SUBDAIO 




1... 


• « • • 






.1.. 


• • • ■ 






..1. 


■ • « • 






...1 


• • • • 






• « • • 


1... 




1 1 


1 




SOBFLGS 




1... 


• • • • 






.1.. 


• • • • 





.1., 



SUBNUM 



The following address constants are always generated; 



4 


4 


4 


8 


8 


4 


2 


C 


4 



16 



10 



SUBDOM Address of the SOBKEY field of the SUB. 

SUBPBASE Address of the base DCM. 

SUBTIOT Address of the task I/O table (in the transient 
DCM control block of the SUB) . 

SUBSPACE Address of the SUB work area (SUBAREA field of 
the SUB). 



The following address constants are only generated if transient DCMs have been defined 
for the system: 



20 



24 



28 



14 



18 



IC 



SUBQOE Address of the DCM request queue (SUBREQ field of 
the SUB) . 

SOBBLDL Address of the DCM BLDL list (SUBTTR field of the 
SUB). 

SUBBLK Address of the DCB (in the transient DCM control 
block of the SUB). 



32 


20 


4 


SUBPFKAD 


36 


24 


Variable 


SUBAREA 


n 


n 


Variable 


SOBKEY 


n 


n 


Variable 


SUBREQ 



Variable 



SOBTTR 



Address of the PFK area. 

Work areas required by the SOB including a CXSA 
save area, a work area, and two register save 
areas. 

Delete-operator-message (DOM) elements. Each DOM 
element is two bytes in length; there is one ele- 
ment for each display console in the system. 

DCM request elements. Each element is two full- 
words in length; there is one element for each 
console in the system that has a transient DCM. 
The first word contains the address of the conso- 
le's OCMENTRY; the second word contains the 
address of the DCM in auxiliary storage. 

Marks the end of the request queue. 
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The following areas contain RMS/SER channel programs used in system recovery procedures. 
The only areas expanded are those areas that support the type of display consoles in the 
systems. 

n n Variable SUB2260 RMS/SER channel programs for 2260 display con- 
soles. This area is expanded only if the system 
includes one or more 2260 display consoles. 

n n Variable SOB5U50 RMS/SER channel programs for the Model 85 and 

Model 165 operator consoles. This area is 
expanded only if the system includes a Model 85 
or Model 165 display operator console. 

n n Variable SUB2250 RMS/SER channel programs for the 2250, Models 91 

and 195 display operator consoles. This area is 
expanded only if the system includes one or more 
of these consoles. 

n n Variable Transient DCM Control Blocks - contain informa- 

tion pertaining to reading and writing transient 
DCMs. This area is expanded only if transient 
DCMs are included in the system. 

n n Variable BASE DCM - executable code which gains control 

whenever an STIMER interval elapses. This rou- 
tine sets flags in the DCM and posts the DCM for 
the Timer Interpreter routine. 
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00 



JOB 


S&HPLDHP 


STEP GO TIHE 001030 DUE 99366 








PAGE 3001 


COHPLETION CODE USEH = 0100 














PSB 


AT ENTKY 


TO ABEND FFF5000D 4005AFD6 














rcB 


03D340 


EBP 0003BC68 PIE 00000000 


DEB 0033B5D4 TIO 


0003D850 


CSP 80300064 


TEN 00000000 






HSS 01040268 PK-FLG F0850400 


FLG 03301B1B LLS 


0003E2D3 


JLB 00000000 


JPQ 00 03 D9 48 






FSA 01068F68 TCB 0003B740 


IHE 00003030 JST 


0003D340 


NTC 00300000 


OTC 00 03D770 






LTC 0003B660 IQE 00000000 


ECB 0003DCF4 STA 


20000000 


D- 


-PQE 00040258 


SQS OO03B46O 






NSTAE 00000000 TCT 0003BDOO 


OSEE O0D030DO DAB 


00000000 


EEs\r 00300000 


JSCB 8703D538 


ftCTIVE KBS 
















PRB 


03E7BO 


BESV 00000000 APSW 00000000 WC-SZ-SIAB 00040082 


FL-CDE 


0003FEB0 PSW FFF5030D 4005AFD6 






Q/TTE 00000000 HT-LNK 0003D340 












SVEB 


030478 


TAB-LN 00180220 APSW F9F0F1Cc 


HC-SZ-SIAB 0012D002 


IQN 


00000000 PSW 00040033 5001902A 






Q/TTH 00011113 ST-LNK 0003E7B0 
















EG 0-7 00000030 30000064 


0033E368 


03000001 


0003D958 


0003D770 


0003D8BC 0003E1D8 






EG 8-15 0003DCD0 0003BDOO 


0003DCF8 


03000000 


4007D482 


0105AD50 


0001DUCA 0039000C 






EXTSA 000029BE 8F068E70 


00000000 


03000000 


FF030300 


0003D4F4 


0003D4FC E2E8E2C9 






C5C1F0F1 C9C5C140 


C1C2C5D5 


C4F90000 










SVEB 


03BC68 


TAB-LN 005803C8 APSW F1F0F5C1 


WC-SZ-SIAB 0012D002 


IQN 


00000000 PSW FFO4OO0C 5005BF&6 






Q/TTE 00010BOD WT-LNK 0003D478 
















EG 0-7 001058B0 0003D4D8 


80018F42 


0301A880 


0303D34C 




0003D478 


0403D340 0003D478 






EG 8-15 0003D340 40018E8A 


0003D340 


8F068E70 


0303D891 




0003D4FC 


4001A1A8 00000000 






EXTSA E2E8E2C9 C5C1F0F1 


00300000 


03000000 


OOOOOOOC 




00000300 


00000300 00090000 






00000000 00000000 


000C1901 


83000C18 










Loao 


LIST 


















NE 0003Et88 ESP-CDE 0103D948 


HE 0003E75: 


ESP-CDE 


0133E650 




HE 0003E898 RSP-CDE 3103FB68 




NE 0003E8ft0 ESP-CDE 0103Fa98 


NE 0003EBEC 


ESP-CDE 


0133FA68 




HE 0003EBE8 BSP-CDE 0103FA38 




NE 00000000 HSP-CDE 0103F908 














CDE 


03FEB0 


AIEl OB NCDE 03ECA8 EOC- 


BB 0003E568 


NM GO 


nsE 


03 


EPA 05AD50 


ATR2 20 XL/MJ 03FEA0 




03D948 


AIE1 03 NCDE 03E650 EOC- 


EB 00000330 


NH IGC0A05A USE 


01 


EPA 05B858 


ATR2 20 XL/MJ 03D838 




03E650 


ATE1 03 NCDE 03FEB0 EOC- 


EB 00000330 


NH IGC0A05A DSE 


01 


EPA 05B058 


ATR2 20 XL/HJ 03E490 




03FB68 


ATE1 BO NCDE 03FBA8 EOC- 


EB 00000330 


NH IGG019CD OSE 


02 


EPA 37CC90 


ATR2 20 XL/HJ 03FB58 




03F498 


ATB1 BO NCDE 03FAD8 EOC- 


EB 00000330 


NM IGG019CJ nSE 


02 


EPA 37C3B0 


ATR2 20 XL/BJ 03FA88 




03Fa68 


ATE1 BO NCDE 03FA98 EOC- 


EB 00000333 


NH IGG019B1 DSE 


02 


EPA 37C208 


ATR2 20 XL/HJ 03F&58 




03FA38 


ATE1 BO NCDE 03FA68 BOC- 


EB 00000300 


NH IGG019BB USE 


02 


EPA 07C828 


ATR2 20 XL/MJ 03FA28 




03F908 


ATB1 BO NCDE 03F938 EOC- 


EB 00000300 


NH IGG019A\f OSE 


01 


EPA 37BBB0 


ATR2 20 XL/MJ 03F8F8 


XL 


03FE40 


SZ 00000010 NO 00000001 


LB 

800002BO 


ADB 
0305AD50 


LN 




ADR 


LN ADE 



D 

a 



13 

K 

rt- 



O 

Hi 



to 



(D 
O 
rf 
H- 
O 


H 
lO 



O 
O 
3 
ft 

O 



H 

o 
o 

CO 

s 
& 

tr 

M 

en 



UI 



















PASS 0002 


03D838 


SZ 


D0000010 


HO 00000001 


800G07i8 


0305B858 








03E't90 


SZ 


D0000010 


NO 00000001 


800007A8 


0305B058 








03FB58 


SZ 


D0000010 


NO 00000001 


80000270 


0007CC90 








03Fi88 


SZ 


D0000010 


HO 00000001 


80000220 


0307C3B0 








03Fft58 


SZ 


D0000010 


NO 00000001 


800001A8 


0307C208 








03FA28 


SZ 


0OOOOO1O 


NO 00000001 


80000128 


0307C828 








03F8F8 


SZ 


00000010 


NO 00000001 


80000080 


0307BBBO 








DEB 


















03B5iO 

03B5C0 000065A8 


00000000 


00000106 00002BEO 


00006543 
11OOOO00 


300065A8 000065A8 0007C3B0 *. 
0433D340 1003D678 88000000 *. 


,..,,.,, .0. , , 


.,,..,.,. c. * 


t • t ; f •••>•• I ! 


* •. J • f • » •, I* • •, 9» 9 » f « * 


03B5E0 8FOO0OO0 
03B600 0004006U 


01000000 
00010001 


1B00OOOO FF068E70 
00000000 00000000 


0403B5BO 
0000007D 


1830206C 00000003 0005000D *. 
C2C2C2C1 C3D1:3C4 00000000 *. 




, . , , * 


f««t*<1<>*«!t 


,. ,,,,PBBACJCD. , ,,* 


03B620 00000000 


00000000 


00000000 00000000 


00000003 


002307DO 


*. 


^•^^••••^••. ji 


J •»••»•••. f »>•.»• f «»•- ? 


DEB 


















03D66D 






00000000 00000000 


00003BEO 


07300000 0003D340 00000000 *. 


••»«••,. •*9f«9 


J • J •- S •. » •. f ! » • L t » , . * 


03D680 08000000 


00000000 


00000000 00000000 


0F05aE9* 


30300000 00003300 33000000 *. 




,.,.,.,.,.,...,,..* 


riOT JOB 


SAHPLDHP STEP 


GO 


PROC TEST 










DD 




14040140 


PGH=*.DD 000A1400 800028A8 








DD 




14000040 


SNAPPER 00OA1800 00000000 








DD 




14040140 


STSABEND OOOBOFOO 3000206C 








DD 




14040100 


DELETE OOOB1AO0 800028A8 








HSS 


>li:*#:tf*7>i*ilHf7tH»:1f 


SPQE ************ 


4:ijc«>K«*4c«:4<««**«A DQE *************** 


*^«*«4i* PQE 


****<<««* 




FLGS NSPQE 


SPID DQE 


BLK 


FQE LN 


HDQE 


NFQE 


LN 


040268 


00 


040398 


251 03ED08 


00051800 0005A800 00000800 


0003DCA0 


00000000 


00000 550 










0005BOOO 3005B000 00000800 


0003D828 


00000000 


00000058 










0005B800 0005B800 00000800 


00000000 


00000000 


00000058 


040398 


00 


0401B8 


252 0401C0 


00069003 30069000 00000800 


00000000 


00000000 


000 007F8 


0401B8 


CO 


000000 


000 040210 












040210 


60 


000000 


000 03FF78 


00063803 30068800 00000803 


3003D650 


00000000 


00 00 63 8 










00063003 30068000 00000800 


00000000 


OOGOOOOO 


00000 1A0 


D-PQE 00040258 


FIRST 00040218 LAST 00040218 










PQE 040218 


FFB 


0005C000 


LFB OOO5C0O0 NPQ 000000D3 


PPQ 00000000 










TCB 


0003D770 


ESI OOOOFOOO RAD 0005A800 


FLG 0000 








FBQE 05C000 


HFB 


00040218 


PFB 00040218 SZ OOOOCOOO 










QCB TRACE 


















MAJ 03DC88 


NHAJ 


00000000 


PflAJ 0001 ECB8 


FHIN 00030C28 NH SYSIEA31 








HIH 03DC28 


FQEL 


0003DC18 


PHIN 0003DC88 


HBIS 00000000 NH 70 lEA 










NQEL 


00000000 


PQEL 0003DC28 


TCB 0003D343 SVRB 0003BC68 









a 

a 
s 



rt 






Ul 

•J 
o 



SAVE AEEA TEACE 



INTEERDPT AT 05AFD6 



PAGE 0003 



CO 






PHOCEEDING BACK VIA REG 13 



0) 



SA 



05AD50 



NOCLEDS 



»D1 90ECD00C 
El 12FF4780 
E7 D03847F0 



HSA 18DF4500 
E2 D02E0700 
E8 F02a3088 



LSA D012E2E'» 
E3 47F0D023 
E9 0005ADA4 



RET 02404040 
E* 80000065 

aio 00000000 



EPA 40404110 
E5 5810D024 
Ell 00000000 



RO D2860A29 
E6 0A0D41F0 
E12 00000000 



o 

Ml 






000000 00000000 00000000 00000000 00000000 

000020 FF040001 4002645C 00000000 00000000 

000040 00018A38 OcOOOOOO 00006E90 0001A880 

000060 00040000 00017690 00040000 00016FDE 

000080 000229EO 00000000 00000000 00000000 

OOOOAO 00000000 00000000 10000060 00034148 

OOOOCO 00000000 00000000 00000000 00000000 

LINES OOOOEO-000140 SAHE AS ABOVE 

000160 00000000 00000000 00000000 82000170 

000180 0004000C 5005BFA6 0000018A 018A018A 

0001A0 OOOOOOCO 0005BB1C 0003D340 9005B9A8 

0001CO 0000078A A005B99C 40018A42 00068D4C 

0001E0 00000000 00000000 00000000 00000000 

LINE 000200 SABE AS ABOVE 

000220 000068FO 00000000 07000700 07000700 

000240 07000700 07000700 OOOOFFOO 00000008 

000260 OOOOFFOO 00010010 2B020000 OOFOFOFI 

000280 06030000 00F0F0F2 10800809 00000000 

0002AO 08040000 00F0F0F3 1000080B 00000000 

0002CO 2B050000 00F0F0F5 56904092 00000000 

0002EO 56904092 00000000 OOOOFFOO 00070010 

000300 OOOOFFOO 00080010 2B080000 OOF0FOF8 

000320 04090004 00F0F0F9 10000820 52DC0000 

000340 10000801 52CC0000 0000FF80 000D0OO8 

000360 0000FF88 000EO008 070COOOO 00F0F0C5 

000380 070D0000 00r0F0c6 10800808 00000000 

0003A0 070E0000 00F0F1F0 10000808 00000000 

0003CO 10010806 00000000 06007D30 00007D38 

0003EO 1001080C 00000000 06007D48 00007D50 

000400 10000808 00000000 OOOOFFOO 00190008 

000420 OOOOFFOO 00U0OO8 OD130000 00F0F1C1 

000440 04140000 00F0F1C6 10000820 00000000 

000460 55114011 00000000 OOOOFFOO 00220010 

000480 OOOOFFOO 00230010 29170000 00F0F2F3 

0004A0 29180000 O0F0F2F4 55114011 00000000 

0004C0 55114011 00000000 OOOOFFOO 00260010 

0004E0 OOOOFFOO 00270010 291B0000 00F0F2F7 

000500 071C0000 00F0F2F8 10000808 00000000 



OG01A830 00300000 01040080 800755CE 

OOOOFFOO 00300000 FF060233 30000000 

083C2C05 0030F198 00040300 00016EE0 

00000003 003229E8 00040000 00016F6A 

00000033 30300000 00003300 30000000 

FF000003 00300000 00000000 00000000 

00000030 30300000 00000300 00000000 

00040033 00374DC0 00000000 00000000 

FF000190 FF300190 00063800 30068D38 

0G05B858 3033B468 00033501 OODF4500 

4005BB38 3037C828 00000000 30000000 

00000003 00300000 00000000 30000000 



07000703 
07010000 
56904092 
06007CF3 
06007D10 
OOOOFFOO 
2B070033 
56904092 
OOOOFF30 
0D0B0003 
10000808 
0200033E 
0008FFOO 
0008FFOO 
0GOOFF33 
OD120003 
10000832 
OOOOFFOO 
29160000 
55114011 
OOOOFFOO 
291A0033 
55114011 
OOOOFFOO 



07300700 
OOFOFOFO 
00300000 
30307DOO 
00307D18 
00360010 
00FOFOF7 
00300000 
303G0008 
00FOFOC4 
52BC0000 
30307D20 
00120018 
30130018 
30180008 
00F0F1F9 
00300000 
00210010 
OOF 0F2F2 
30300000 
00250010 
30FOF2F6 
00300000 
00290008 



07003703 
10000803 
0008FFOO 
0008FF00 
OOOOFFOO 
2B060000 
56934392 
O0OOFF82 
0D0A3300 
10000802 
0008FFOO 
OOOOFFOO 
OBOFOOOO 
0B103300 
07113300 
10000801 
OOOOFFOO 
29150000 
51114051 
OOOOFFOO 
29190000 
51114311 
OOOOFFOO 
0D1D0000 



07300700 
30003000 
00020018 
30030018 
00050010 
30F0F0F6 
00000000 
00090008 
30F0F0C3 
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000F0O20 
30100008 
30F0F1F2 
30F0F1F3 
00F0F1F8 
00000000 
391F0008 
30F0F2F1 
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00240010 
00FOF2F5 
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30280008 
00F0F2F9 
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w 
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a 
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(D 
en 






002780 
002760 
027CO 
0027E0 
002800 
002820 
002840 
002860 
002880 
002840 
0028CO 
0028E0 
002900 
002920 
002940 
002960 
002980 
002950 
0029C0 
0029E0 
002A00 
002A20 
002A40 
002A60 
002A80 
002AA0 
002AC0 
OO2&E0 
002B00 
002B20 
002B40 
002B60 
002B80 
002BAO 
002BC0 
002BE0 
0O2C0O 
002C20 
002C40 
002C60 
002C80 
002CA0 
002CC0 
002CE0 
002DOO 
002D20 
002040 
002D60 
002D80 
02DA0 
002DC0 
OO2DE0 
002E00 
002E20 
002E40 



00000000 
30C02008 
00000000 
30C02008 
00000000 
30C02008 
00000000 
10000820 
00000000 
01000000 
00000000 
02000000 
00000000 
00000000 
00400000 
00000000 
00400100 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
18009E40 
00000000 
18009EE8 
00000000 
18009F90 
00000000 
1800A038 
00000000 
18OOA0EO 
00000000 
1800A188 
00000000 
1800A230 
00000000 
1800A2D8 



00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
F7F7F7F7 
000098D8 
F9F9r9F9 
00009928 
00000000 
00009978 
E2E8E2D9 
000099C8 
E2E8E2D3 
00009A18 
00000000 
00009A68 
00000000 
00009AB8 
00000000 
00009B08 
00000000 
00009B58 
00000000 
00009BA8 
00000000 
00009BF8 
00000000 
00009C48 
00000000 
00009C98 
00000000 
00009CE8 
00000000 
00009D38 
00000000 
00009D88 
00000000 
00009E08 
00000000 
O0009EB0 
00000000 
00009F58 
00000000 
OOOOAOOO 
00000000 
0000A0A8 
00000000 
0000A150 
00000000 
0000A1F8 
00000000 



00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
00000000 
0001FF88 
F7F70800 
F001FF88 
F9F90801 
0001FFOO 
00000000 
F001FF86 
C5E20800 
F001FF84 
C9C20801 
0001FF00 
00000000 
00C1FF00 
00000000 
0001FFOO 
00000000 
OOOOFFOO 
00000000 
OOOOFFOO 
00000000 
OOOOFFOO 
00000000 
OOOOFFOO 
00000000 
OOOOFFOO 
00000000 
OOOOFFOO 
00000000 
OOOOFFOO 
00000000 
OOOOFFOO 
00000000 
0008FF00 
00000000 
0008FFOO 
00000000 
0008FFOO 
00000000 
0008FFOO 
00000000 
0008FF00 
00000000 
0008FF00 
00000000 
0008FF00 
00000000 
0008FFOO 
00000000 



00009798 
00000000 
000097E8 
00000000 
00009838 
00000000 
00009888 
02300048 
00040100 
02310048 
00010100 
02324048 
00000000 
02330048 
00040100 
02340048 
00040100 
02354048 
00000000 
02364048 
00000000 
02374048 
00000000 
02404060 
00000000 
02414060 
00000000 
02424060 
00000000 
02434060 
00000000 
02444060 
00000000 
02454060 
00000000 
02464060 
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00000001 
2003F4C8 
00000001 
2803F508 
00000000 
0003F4F8 
00000000 
00000001 
2003F5A8 



0003EF40 
C9C6C7rD 
00073000 
C9C6C7F0 
80000400 
0003EFF0 
80000400 
OO03FO20 
C9C7C7F0 
00074000 
C9C6C7F0 
80000400 
0003FODO 
80000400 
0003F100 
C9C6C7F0 
00075000 
C9C6C7F0 
80000400 
0003F1BO 
80000400 
0003F1EO 
C9C6C7F0 
00076000 
C9C6C7F0 
80000400 
0003F290 
80000400 
0003F2CO 
C9C6C7F0 
0007700D 
C9C6C7F0 
80000400 
0003F370 
8000040D 
0003F3AO 
C9C7C7F0 
00078000 
C9C7C7F0 
80000400 
0003F450 
60000400 
0O03F480 
C9C7C7F0 
00079000 
C9C7C7F0 
80000400 
0003F530 
80000400 
0003F550 
C9C7C3F0 
0007AOOO 
C9C7C3F0 
800001D3 
0003F600 



0103EF28 
F2fOF2Dl 
00000800 
F2?0F2D2 
00D7380O 
0103EFD8 
00073COO 
01D3F008 
F2F0F1E8 
00000800 
F2F0F0E8 
OOD74800 
O103F0B8 
00074COO 
Oia3FOE8 
F1F9F8D5 
00300800 
Fif 9F6E6 
00075800 
0103F198 
00075COO 
0103F1C8 
F1f9F6D3 
00000800 
F1F9F6D1 
00076800 
0103F278 
00076COO 
0103F2A8 
F1?9F5D1 
00000800 
F1F9F5C1 
00377800 
0103F358 
00077COO 
0133F388 
F1F9F1F7 
00300800 
F1F9F1F1 
00078800 
0103F438 
00078CO0 
0133F468 
F1F9F1C2 
00000800 
F1F9F1C1 
00079800 
0103F518 
00379COO 
0133F548 
F0F0F2C2 
00300800 
F0F0F1C9 
0037A918 
0103F5E8 



00000010 
01073300 
00000010 
01073400 
B103EFD8 
00000000 
B103F008 
00000010 
01074000 
00000010 
01074400 
B103F0B8 
00000000 
B103FOE8 
00000010 
01075000 
00000310 
01075400 
B103F198 
00003000 
B103F1C8 
00000010 
01076300 
00000010 
01076400 
B103F278 
00000000 
B103F2A8 
00000010 
01077000 
00000010 
01077400 
B103F358 
00000000 
B103F388 
00000010 
01078000 
00000010 
01078400 
B003F438 
00000300 
B003F468 
00000010 
01079000 
00000010 
01079400 
B103F518 
00000000 
B103F548 
00000010 
0107A278 
00000010 
0107A520 
B103F5EB 
00000010 



00000001 
2803EF18 
00000001 
2803EF58 
00000000 
0003EF48 
30000000 
00000001 
2003EFF8 
00000001 
2803F038 
00000000 
0003F028 
00000000 
00000001 
2803F0D8 
00000001 
2803F118 
00000000 
0003F108 
00000000 
00000001 
2803F1B8 
00000001 
2803F1F8 
00000000 
0003F1E8 
00000000 
00000001 
2803F298 
00000001 
2803F2D8 
00000000 
0003F2C8 
00000000 
00000001 
2803F378 
00000001 
2003F3B8 
00000000 
0003F3A8 
00000000 
00000001 
2003F458 
00000001 
2003F498 
00000000 
0003F488 
30000000 
00000001 
2803F538 
00000001 
2803F578 
00000000 
00000001 
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0404A0 4F0000OO 01000000 FFOOOOOO 0F071728 04040470 18002928 00000343 00010044 
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REGS AT ENTRY TO ABEND 

FLTR 0-6 000000000003D478 
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osaEiO 

05AEC0 
05AEE0 
05AF00 
05AF20 
05AF40 
05AF60 
05AF80 
05AFA0 
5AFC0 
5AFE0 



00000000 
0003D678 
00000001 
40404040 
40404040 
33333333 
77777777 
BBBBBBBB 
FFFFFFFF 
40404040 
D7071000 



00000000 
9207BBF6 
0000007D 
40404040 
40404040 
33333333 
77777777 
BBBBBBBB 
FFFFFFFF 
40404040 
10004110 



LOAD HODDLB 



IGC0A05A 



05B840 
05B860 
05B880 
05B8A0 
05B8C0 
05B8E0 
05B900 
05B920 
05B940 
05B960 
05B980 
05B9A0 
05B9C0 
05B9E0 
05B400 
05BA20 
05BA40 
05BA60 
05BA80 
05BAA0 
05BAC0 
05BAE0 
05BB00 
5BB20 
05BB40 
05BB60 
05BB80 
05BBA0 
05BBC0 
05BBE0 
05BC00 
5BC20 
05BC40 
05BC60 
05BC80 
05BCA0 
05BCC0 
05BCE0 
05BD00 
05BD20 
05BD40 



00001A81 
8CE00004 
F384D069 
41330001 
D12094FC 
D06C1810 
66804000 
4120D121 
46A06104 
D0704120 
9640D112 
47B061A6 
41220020 
D06E1211 
D06E0610 
D1124550 
41306297 
45B0623E 
627C1B00 
41111001 
2000D200 
C1E240C1 
03FF1B03 
D09441FF 
41FE0004 
100858F0 
1A019240 
47F060E2 
D10AD07C 
078547F0 
D1384710 
D1394710 
007C13EE 
188E18AE 
4550639A 
0A0A47F0 
41FF0004 
6568181D 
D13841A0 
655047FO 



41330001 
88F0001C 
D069DC07 
47F060E2 
D1235B00 
54006290 
D06A1211 
45B06236 
9640D112 
D07i45B0 
455062DA 
18125B10 
5020D120 
4780619E 
12114770 
62DA94BF 
45B0623E 
O20DD0B2 
43030000 
4410628A 
8000D070 
C2D6E5C5 
FF2403FF 
007D50FO 
50F0D084 
E03405EF 
D098D277 
4810D05E 
96F0D10D 
62FCD7C1 
64C69101 
64D29118 
45506504 
47F06694 
9879D080 
67 589180 
41300004 
41110000 
653847F0 
64FA94FD 



00000001 
0007BBDE 
0007BBB0 
40404040 
40404040 
44444444 
88888888 
CCCCCCCC 
40404040 
47F0D280 
10004100 



95FF3000 
8C000004 
D06962C6 
D2008000 
D1201A10 
19014780 
4770611C 
5820D120 
455062DA 
62364810 
94BFD112 
6680D51F 
46A0615E 
5810D120 
6202D203 
D112D701 
9260D0AB 
62A247F0 
1B114313 
41330002 
FFFFFFEO 
0002FF09 
3003FF39 
D084411F 
47F06722 
OA030700 
D099D098 
41110001 
D201D05C 
C7C5FFFF 
D1384710 
D1394750 
47F06418 
4700640C 
12774780 
E0024780 
92FF1000 
OAOA4100 
64FA94F3 
D13994EF 



00004000 
00000001 
C010D503 
404040E2 
40404040 
44444444 
88888888 
CCCCCCCC 
40404040 
80000064 
00010A01 



47806068 
8810001C 
41FFF001 
3002D200 
5800D120 
60BC1B10 
4810D06A 
413062C4 
94BFD112 
D06C8810 
4810D06C 
10002000 
47F061B0 
4800D06E 
D09F629D 
D06ED06E 
5810D120 
61E64130 
00011A80 
41220004 
0B02FF0C 
0312031B 
03FF4203 
007D1910 
92201005 
47F 06770 
41100038 
4010D05E 
63B247F0 
07FEF0F1 
668C9180 
64E29110 
47F06434 
94FE401D 
646A1B97 
64A24110 
42301001 
6560D205 
D13894DF 
D13841A0 



00000001 
00000000 
4 04 04 043 
E3D6D9C1 
11111111 
55555555 
99999999 
DDODDDOD 
40404040 
5810D27C 
4 7F0Fd22 



04D00001 
00000000 
40404040 
C7C540E3 
11111111 
55555555 
99999999 
DDODDDDD 
40404040 
OAOD4100 
80300066 



1 BEE1 BFF 
1A2044EO 
44F06 07C 
D0692000 
41110003 
4010D06C 
12114770 
48A0D05A 
4 7F 06 ODE 
00011A31 
12114770 
477061A6 
1B114010 
89000005 
41306294 
12AA4780 
5B106680 
62B047F0 
44106284 
47F0623E 
02FF1302 
03240330 
FF0098EO 
47D06332 
58F10008 
9560D098 
190147B0 
92F1D098 
620A98EO 
F2F3F4F5 
D13947F0 
D1384710 
947FE020 
D20BD098 
410000FA 
D070I)70B 
50E01004 
AOe064C0 
D13941A0 
655841F0 



1BJ01B11 
60701A1E 
47F066F8 
D2008000 
5010D064 
5810D064 
60E85850 
4BA0D06C 
18415810 
5820D120 
51984700 
4810D06E 
D05C46A0 
1B105010 
45B0623E 
60I)447FO 
5010D070 
65744180 
F334D070 
41330001 
FFD3C9D5 
03390342 
D08012EE 
1BFE40F0 
58F0F030 
47406348 
63SC400O 
D203D105 
D03012EE 
F5F7F8F9 
6616910C 
66C69102 
58100010 
652CD203 
89300018 
10001000 
50F01008 
47FA0060 
654847F0 
D07050AO 



54000000 
O0O7BBE0 
40404040 
C5E2E340 
22222222 
66666666 
AAAAAAAA 
EEEEEEEE 
40404040 
00084510 
5810F01E 



4180D099 
43E30000 
41818001 
413E3003 
D0695050 
94FCD067 
4A10D06C 
D08C5860 
88A00002 
D1204B10 
45B0623E 
615E4110 
41110001 
611E47F0 
D0704120 
D20DD0AA 
619ED204 
4120D071 
D09995FF 
D070DC07 
07FBE2E2 
C5E24 0E2 
034B03FF 
47805310 
D090D203 
05EF5817 
47206346 
D05C9140 
63AE4E10 
0785411E 
C1C2C3C4 
D1384750 
D1394710 
58B010C8 
D124D128 
16091817 
41E0556C 
OA3O5 8A0 
0A091BFF 
64FA94E7 
F0000A07 



002C0020 
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40404040 
C1D9C5C1 
22222222 
56666666 
AAAAAAAA 
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40404040 
F0080A0A 
0A0D1020 



1B114313 
43030001 
44F06076 
47F06010 
D08C5000 
D703D06C 
1B005D00 
D12407F5 
45B0623E 
D06C5010 
5020D120 
0001191A 
4010D06E 
60D44810 
D0714810 
62A29640 
D09F629D 
4130629A 
30004780 
D07062C6 
D200D070 
C1D4C540 
0903FF12 
D27CF00O 
E000D090 
000058EO 
U011A01 
D1120715 
D078F333 
0004191F 
C5C69120 
64D29120 
64EE58E4 
58BB0028 
455062DA 
41110000 
58FOD060 
D1305800 
0A0394DF 
D13941A0 
12EE47A0 
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SECTION 13; CHARTS 



The flowcharts are arranged, in general, in the order in which the routines are 
described in this publication. Each flowchart contains entry point names, common routine 
names, and labels that appear in the listings. 

A subroutine block can contain as many as three names: the label from the listing 
used when the subroutine was invoked, the subroutine's common name used in both the list- 
ing and the manual, and the subroutine's entry point name. The label from the listing 
appears at the top left of the block; the common name and the flowchart identification 
appear inside the block; the entry point name appears at the top right of the block. An 
(S) after the entry point name means that the subroutine (or routine) is invoked via 
supervisor linkage (the SVC interruption handlers) . The supervisor linkage path is not 
shown on each flowchart. It is shown, however, in the overall control flow. Chart 00. 

LISTING LABEL ENTRY POINT NAME 
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JANY ROUTINE CDA2 (Flowchart ID)) 
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I 1 

I I 
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Link, Load, XCTL and 


TTIMER 


ABDUMP 
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The Overlay Supervisor and the Link, 
Load, XCTL and Synch Routine are 
Both Type 2 SVC Routines 
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chart AA. SVC First-Level Interruption Handler 



lEAQNUOO. 



r~ ^ 

f SVC FLIH \ 



lEAQSCOO 



.B2- 



PLACE REGISTER 

CONTENTS INTO 

SVC REGISTER 

SAVE AREA LOC 

lEflSCSAV 



THIS EXIT APPLIES 
ONLY TO MODEL 6S 
MULTIPROCESSING 
SYSTEMS 



EID=IHLMSVC 
RECORD SVC 
INTERRUPTIONS 



0- 



PLACE PERTINENT 

INFO INTO TRACE 

TABLE 



USING SVC NO. 

IN SVC OLD PSW, 

LOCATE ENTRY Ti 

SVC TABLE 



REGISTER 14 SET TO 
CAUSE ABTERM TO EXIT 
TO THE DISPATCHER 

,P3_ 



TVPE 1 SVC ROUTINES 


CHAP . . 


. BE 


EXIT . . 


. KB 


EXTRACT . 


. BD 


FREEMMN 


. DA 


GETMAIN. 


. DA 


POST . . 


. BH 


TIME . . 


. EA 


TTIHER . 


. EC 


WAIT . . 


. BG 




r~ ^ 

f SVC SLIH 1 
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chart AB. SVC Second-Level Interruption Handler 



IEAQTR33 



( SVC SLIH j 



lEAQTROO if IGC004CS) 




INITIALIZE 

SVRB. QUEUE ON 

CALLER'S TCB 



INDICATE IN 
SVRB THAT 

ROUTINE IS 
RESIDENT 




TYPE 2 SVC ROUTINES | 


ATTACH .... 


BA 


DELETE .... 


CC 


DEO 

DETACH .... 


BJ 


BE 


STRGEi 


BI 




EXIT EFFECTOR. 


8K 


IDENTIFY . . . 


CB 


LINK, LOAD. XCTL 
AND SYNCH . . 




CA 


OVERLAY SUPER- 




VISOR .... 


CE 


SPIE 


BF 


STIMER .... 


EB 


TYPE 3 SVC ROUTINES | 


STAE SERVICE . 


BP 


WTO,WTOR . . . 


FB,FC 


WTL 


GB 


TYPE 4 SVC ROUTINES | 


ABDUMP .... 


LI 


ABEND .... 


LL-LY 


CHECKPOINT . . 


JA-JI 


COMM TASK ROU- 




TER 


. FG 


LOG AND WRITE- 




LOG POST. . . 




RESTART. . . . 


JJ-JW 



MOVE LENGTH, 

TTR, AND NAME 

OF ROUTINE INTO 

CALLER'S SVRB 




INDICATE THAT 

TRANSIENT AREA 

BLOCK (TAB) IS 

IN USE 



TA AVAIL CHK AD 



FIND AVAILABLE 

TRANSIENT AREA 

BLOCK (TAB) 



QUEUE CALLER'S 
SVRB ON USER 
QUEUE FOR TAB 




INCREMENT 

TRANSIENT AREA 

USER COUNT 



u. 



PLACE CALLER 

INTO WAIT 

STATE, QUEUE 

SVRB ON REQUEST 

QUEUE 



1 



PREPARE TO 

OVERLAY THE 

ROUTINE IN THE 

TAB 



QUEUE CALLER'S 
SVRB ON USER 
QUEUE FOR TAB 



INCREMENT 

TRANSIENT AREA 

USER COUNT 



SET POINTER TO 

NEXT AVAILABLE 

TAB 



SET UP INPUT 

REGS AND PLACE 

CONTENTS IN 

CURRENT TCB 



PLACE CALLER 
INTO WAIT STATE 
AND PREPARE FOR 
LOADING OF RTN 



SET UP TASK 

SWITCH TO 

TRANSIENT AREA 

FETCH TASK 



RB OLD PSW IS 

SET FOR ENTRY TO 

TAB FROM THE DISPATCHER 



THE TRANSIENT AREA 
FETCH ROUTINE 
WILL CAUSE THE REQUESTED 
ROUTINE TO BE LOADED. 



TURN ON LOADING 

INDICATOR IN 

TRANSIENT AREA 

CTL TBL (TACT) 

ENTRY 



»>f DISPATCHER j 
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Chart AC. Extended SVC Router 
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CAUSE ABTERM 
TO EXIT TO 
DISPATCHER 



EP=IEAOABOO 




EXIT TO SERVICE 
ROUTINE VIA 
AN XCTL 



C— 1 
TYl 



EXIT TO SERVICE 



TYPE 1 OR 2 \ ROUTINE VIA 
ROUTINE JA BRANCH 
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Chart AD. Transient Area Availability Check Routine 



IEAQTR33 
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chart AE. Transient Area Fetch Routine 
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IEAQTR33 
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ENTRY FOR TRANSIENT 
, ROUTINES OTHER THAN 
■RANSIENT AREA\ FIRST LOAD 



D 
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FROM DISPATCHER 
CHART KF 
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INITIALIZE FOR 

BLDL ENTRY USE 

TCB TABLE 
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LOADING 
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Chart AF, Program Check First-Level Interruption Handler (Page 1 of 2) 
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( FLIH \ 



-B2- 



ENTERED FOLLOWING 
PROGRAM CHECK 
INTERRUPTION 



PLACE REGISTER 

CONTENTS INTO 

PROGRAM CHECK 

REGISTER SAVE 

AREA 



~1 



NOTE - THIS EXIT APPLIES 
ONLY IN MODEL 65 MULTI- 
PROCESSING SYSTEMS 




NOTE - THIS EXIT APPLIES 
ONLY IN MODEL 65 MULTI- 
PROCESSING SYSTEMS 



MONITOR CALL 

INTERRUPTION 

HANDLER 



PLACE ENTRY PT 

OF INTERRUPTED 

ROUTINE INTO 

PROG OLD PSW 



EID=IHLMPI 
RECORD PROGRAM 

INTERRUPTION 



-Da- 
PL ACE RETURN 
ADDRESS INTO 
REGISTER 14, 
RESTORE 

REGISTERS 



PLACE PERTINENT 

INFO INTO TRACE 

TABLE 
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ERROR- HANDLING 
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PLACE PROG OLD 
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PLACE ADDR OF 
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IN PROGRAM 
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CONTROL AREA 
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Chart AF. Program Check First-Level Interruption Handler — Multiprocessing (Page 2 of 2) 
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LOCK BYTE, 

PLACE CPUID IN 

IDENTITY BYTE 



RESET PROG. 

CHECK FLIH BIT 
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LOCK BYTE, 

PLACE CPUID IN 
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PLACE NEW MASK 
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OLD PSW 



SET PROG. CHECK 
OLD PSW TO 
REISSUE SSM 
INSTRUCTION 



w (OPTIONAL) 



PLACE PERTIN. 
INFO. INTO 
TRACE TABLE 
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-H4- 




PLACE ENTRY PT 

OF ERROR RTN IN 

PROG OLD PSW, 

SAVE REGS IN 

TCB 



RESTORE 

REGISTERS FROM 
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SSM INDIC IN 
INTERRUPT CODE 
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CHECK OLD PROGRAM 



SET RB PSW AND 
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EQUAL TO PROG. 
CHECK OLD PSW 
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SSM INDIC IN 
INTERRUPT CODE 



DISPATCHER 
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I EXTERNAL FLIH \ 
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Chart AG- Program Check First-Level Interruption Handler — Models 91 and 195 
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/PROGRAM CHECK ^ 
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MONITOR CALL 

INTERRUPTION 

HANDLER 
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HOOK 




EID=IHLMPI 

RECORD PROGRAM 

INTERRUPTION 


TRPI 




TRACE RTN 




PLACE PERTINENT 

INFO INTO TRACE 

TABLE 





y B5 ^ 

/TESTRAN ERROR \ 
( RTN j 




r~' — ^ 

(ABTERM PROLOGUEJ 



NOTE CI: BLOCKS D1-H1 AND E2-J2 ARE USED 
ONLY WHEN THE DECIMAL SIMULATOR 
IS INCLUDED IN THE SYSTEM, 
OTHERWISE, BLOCK CI CONNECTS TO 
BLOCK A3. 



NOTE H^: ARE ALL IMPRECISE INTERRUPTS, 
THAT HAVE BEEN RECEIVED, 
EXPECTED? 
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Chart AH. External First-Level Interruption Handler — Uniprocessing 



lEAQNUOO 



( EXTERNAL FLIH \ 



PLACE REGISTER 

CONTENTS INTO 

CURRENT TCB 





c- + 






WAIT TIME MO 




COMPUTE WAIT 

TIME IF SYS WAS 

IN WAIT STATE 




1 





PLACE EXTERNAL 
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RECORD EXTERNAL 
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TIMER SLIH 



404 



Chart AI. External First-Level Interruption Handler — Multiprocessing 
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EID=IHLMEXT 

RECORD EXTERNAL 

INTERRUPTIONS 
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Chart AJ. Input/Output First-Level Interruption Handler 
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WAIT TIME 
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NOTE: THIS EXIT APPLIES 
ONLY TO MODEL 65 MULTI- 
PROCESSING SYSTEMS 



PLACE PERTINENT 
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TABLE 
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INDICATION OF 
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BYTE, PLACE 
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INTERRUPTIONS 
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CHART KF (UNIPROCESSING) 

CHART KJ (MULTIPROCESSING) 
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Chart AK. SERO Routine 
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MACHINE CHECK 
INTERRUPTION 



SAVE REGS 13, 
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SAVE CSW, PSW, 

AND DIAGNOSTIC 
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RECORD ENTRY 
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ENABLE MACHINE 
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HALT ALL I/O 

ACTIVITY 




USE DIAGNOSE 

INSTRUCTION TO 

CHECK GENERAL 

REGISTERS 



PT 
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CHK PARITY OF 
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FLT POINT REGS 
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CONTENTSIN RCD 




ENTRY 
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USE DIAGNOSE 
INST TO CHK FLT 

POINT REGS. 
COMPRESS GEN £ 
FLT POINT REGS 




MOVE ACTIVE I/O 
UNITS, DEV 

TYPE, CCW, AND 

JOB NAME TO 

RECORD ENTRY 
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UPDATE HEADER; 

WRITE 

ENVIRONMENT 

RECORD AND EOF 



USE ' FQ9' WAIT 

CODE SET UP 

SEREP INTERFACE 

PRINT MSG 



-Dl- 



READ FIRST 

PORTION OF 

IFBSEROO FROM 

SYSl .LINKLIB 

DATA SET 



-El- 



SET UP PTR TO 

SAVED DATA, 

DISABLE MACHINE 

CHECK 

INTERRUPTIONS 



LOAD PSW FOR 
ENTRY TO 
IFBSEROO 



) 



CHART AK/A2 
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Chart AL. SERl Routine — Models 40, 50, 65, and 75 
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MACHINE CHECK OR 
CHANNEL CHECK 
INTERRUPTION 




-B2- 



MOVE CHANNEL 

LOG FROM 

DIAGNOSTIC SCAN 

OUT AREA TO 

RECORD ENTRY 
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MOVE CSW, CHAN 
ID, CHAN UNIT 
ADDR TO RECORD 
ENTRY MOVE CHAN 
ADDR TO MESSAGE 



1. 



RESET 

DISPATCHABILITY 

FLAGS 



MOVE PROGRAM 

NAME AND JOB 

NAME TO RECORD 

ENTRY 



-Ba- 



MOVE ALTERNATE 

I/O UNITS 

DEVICE TYPE CCW 

AND JCB NAME TO 

RECORD ENTRY 



SCHEDULE 

TERMINATION OF 

JCB STEP 



MOVE CPU LOGOUT 
FROM DIAGNOSTIC 

SCAN OUT AREA 
TO RECORD ENTRY 



MOVE MACHINE 

CHECK OLD PSW 

TO RECORD ENTRY 
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INDICATE 

STAND-ALONE I/O 

AND SYSTEM 

TERMINATED 



r J. , coYt , I'll- 
PSW, ETC. 



PLACE CONTENTS 

OF GENERAL 

PURPOSE 

REGISTERS IN 

RECORD ENTRY 




SET ALL TASKS 
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SET CURRENT 

TASK MUST 

COMPLETE 



CHECK 


PARITY 1 


AND 


PLACE 


CONTENTS OF 1 
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RECORD 


ENTRY 1 



IF AVAILABLE, 

PLACE CONTENTS 

OF FP REGISTERS 

INTO RECORD 

ENTRY 



CHECK PARITY 

AND PLACE 

CONTENTS OF FP 

REGISTERS INTO 

RECORD ENTRY 



OBTAIN DATE AND 

TIME OF FAILURE 

FROM CVT, PLACE 

INTO RECORD 

ENTRY 




D3J ^ 

( DISPATCHER J 



WRITE 

ENVIRONMENT 

RECORD AND EOF 
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Chart AM. SERl Routine — Models 91, 95, and 195 (Page 1 of 2) 




MOVE DATE TIME 
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RECORD ENTRY 

TIME STAMP 

MESSAGE 



MOVE DATA FROM 
BUFFER TO ROD 
AREA, SHOW EXT 
AND CHAN. DATA 
IN SAME RECORD 



E' " 


ABTERM LF 


TERMINATE 
CURRENT TASK 



MOVE PROGRAM 

NAME AND JOB 

NAME TO RECORD 

ENTRY 
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SET STAND ALONE 

I/O. HALT 

SYSTEM I/O 
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SET OTHER TASKS 

NONDISPATCHABLE 

SET CURR TASK 

MUST COMPLETE 



B' 



READ AND UPDATE 

HEADER RECORD 

WRITE 

ENVIRONMENT 

RECORD AND EOF 




MOVE CSW CHAN 

ID UNIT ADDR TO 

RECORD ENTRY 

CHAN ADDR TO 

MSG 



ISSUE WARNING 

MESSAGE AND SET 

SWITCH 



MOVE ACTIVE I/O 

UNITS DEVICE 

TYPE CCW AND 

JOB NAME TO 

RECORD ENTRY 
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DISPATCHER 



) 



MOVE RECORD 
DATA FROM 
BUFFER TO 

RECORD AREA 
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Chart AM. SERl Routine — Models 91, 95, and 195 (Page 2 of 2) 



r~ ^ 

I ENTRY 1 



ENTERED FOLLOWING: 
SECOND MACHINE CHECK 
SECOND EXTERNAL CHECK 
CHANNEL CHECK 





SET OTHER TASKS 

DISPATCHABLE. 

NO ASYNCH 

INTERRUPTIONS. 

ENABLE I/O LOOP 
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DISABLE I/O. 

CLEAR CHANNEL. 

MOVE RCD FROM 

BUFFER TO BF 

AREA 
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Chart BA. Attach Routine (Page 1 of 5) 



lEAQATOO 




PLACE RETURN 
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REG 15 
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GETMAIN DA 




GET SPACE FOR 
TCB, SP 253 
(215 BYTES) 







INITIALIZE TASK 
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INITIALIZE 

INTERRUPTION 

REQUEST BLOCK 
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Chart BA. Attach Routine (Page 2 of 5) 




NOTE: IS ECB KEY = 

ATTACHER'S KEY OR 
IS ATTACHER'S KEY 
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Chart BA. Attach Routine (Page 3 of 5) 






r~ ^ 
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^YES 


c- " 




SET SUBPOOL ID 



GET ADDRESS OF 

POINTER TO 

FIRST CDE 




BUILD SPQE, 

QUEUE TO 

ATTACHER'S TCB 





BLDSPQE 



BUILD SPQE, 

QUEUE TO 
CREATED TCB 








REMOVE SPQE FRM 
ATTACHER'S TCB, 
QUE ON NEW TCB 



GIVE251 _^ w 




SET SUBPOOL ID 



REMOVE SPQE FRM 
ATTACHER'S TCB 
QUE ON NEW TCB 



TRANSFER JOB 

PACK POINTER 

FROM ATTACHER'S 

TCB TO CREATED 

TCB 



ZERO OUT JOB 
PACK POINTER IN 
ATTACHER'S TCB 
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Chart BA. Attach Routine (Page 4 of 5) 






PLACE ADDR OF 

REG 14 FIELD OF 

SVR8 INTO REG 1 

FIELD OF TCB 

REG SAVE AREA 



PLACE ADDR OF 

GETSAVE CHART 

INTO CREATED 

TASK'S SVRB 



PUT ADDRESS OF 

LOGON IN 

TJBXFST AND 

TJBXLAST 



C3 " 


PLACE ADDR OF 
REG la FIELD OF 
SVRB INTO REG 1 



r^" ^ 

( DISPATCHER J 



TASK SWITCH 



DETERMINE IF 

TASK SWITCH IS 

NECESSARY 



TRANSFER REGS. 

FROM SVRB TO 

ATTACHER'S TCB 



SET NUMBER OF 

TS TCBS IN TJBX 

TO ONE 



CHAIN ISSUER 

AND LOGON'S 

TCBS 



PLACE CVT, TCB, 

AND SVRB ADDR 

INTO CREATED 

TCB 



PLACE ADDRESS 

OF CREATED TCB 

INTO ATTACHER'S 

TCB 








PLACE ADDR OF 

CD CONTRL CHART. 

INTO CREATED 

TASK'S SVRB 



i 



PUT TCB ON 

QUEUE BY TS 

DISPATCH 

PRIORITY 



COMPLEMENT 
SPECIFIED ADDR 
AND PLACE INTO 
REG 1A FIELD OF 
SVRB SAVE AREA 



DISPATCHER 



3 



INCREMENT 

NUMBER OF 

ACTIVE TCBS IN 

TJBX 



MOVE ENTRY 
POINT NAME INTO 

REG la AND 15 
FIELDS OF SVRB 

REG SAVE AREA 



GETMAIN DA 




GET SPACE FOR 
SAVE AREA. 7 2 
BYTES, SP=250 







REMOVE SVRB 

FROM ATTACHER'S 

RB QUEUE, PLACE 

ON CREATED TASK 

RB QUEUE 



( REENTER \ 

FROM DISPATCHER 




PLACE ADDRESS 

OF SAVE AREA IN 

CREATED 



QPL=QUIESCE PARAMETER LIST 



-Kl- 



TRANSFER DCB 

ADDRESS TO 
CREATED TCB'S 
REG SLOT IN 
REG SAVE AREA 



L 



CLEAR SAVE AREA 



PLACE ADDRESS 

OF SAVE AREA IN 

CREATED TASKS' 

SVRB 







L, 



LARGER QPL 



UPDATE TJBX AND- 

NUMBER OF QPL 

ENTRIES 



L 
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Chart BA- Attach Routine (Page 5 of 5) 



SEE NOTE 1 




MOVE LIMIT PRTV 

FROM ATTACHER'S 

TCB TO CREATED 

TCB 



SUBTRACT 

SPECIFIED LIMIT 

PRTY EROM 

ATTACHER ' S 

LIMIT PRTY 




GET ATTACHER'S 
DISP PRTY FROM 

TCB 5 ADD 

SPECIFIED DISP. 

PRTY 



SEE NOTE 1 




MOVE 255 TO 

DISP. PRTY. OF 

CREATED TCB 



U 



© 




IF ATTACH IS ISSUED 

BY A TIME-SHARING TASK, 

THE TIME-SHARING DISPATCHING 

AND LIMIT PRIORITIES ARE USED. 



MOVE RESULT TO 

DISP PRTY OF 

CREATED TCB 




MOVE LIMIT PRTY 

TO DISP PRTY IN 

CREATED TCB 




TIME SLICING 



STORE ADDR OF 

CREATED TCB IN 

LAST SLOT IN 

TSCE 




STORE ADDR OF 

CREATED TCB IN 

FIRST £ NEXT 

SLOT IN TSCE 



L 



B 
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chart BB. Chap Routine 



r' — ^ 

( CHAP \ 









ADD PRIORITY 

CHANGE TO DISP 

PRIORITY OF 

SUBJECT TCB 



f BRANCH ENTRY j 








SET DISPATCH 

PRIORITY OF 

SUBJECT TCB TO 

ZERO 



SET DISPATCH 

AND LIMIT 

PRIORITY TO 

LIMIT OF PARENT 

TASK 



K2 1 

SET DISPATCH 

AND LIMIT 

PRIORITY TO 

LIMIT OF PARENT 

TASK 



n 



PLACE RESULT 

INTO DISPATCH 

PRIORITY FIELD 

OF SUBJECT TCB 




REORDER TCB 

QUEUE BY NEW 

PRIORITY 



SET LIMIT 

PRIORITY OF 

SUBJECT TCB TO 

DISPATCHING 

PRIORITY 



TASK SWITCH BN 



^K5 ^ 

*■( TYPE 1 EXIT j 
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Chart BC. Chap Routine with Time-Slicing (Page 1 of 3) 




TIME SLICING 



GET ABTERM 

ADDR-VAL CK 

ADDR-SAVE ADDR 

OF TCB ADDR 




RESTORE INPUT 

REG, GET TCB 

ADDR 







GET SUBTASK TCB 


ADDR 







STORE REQ. TCB 
LIM. PRTY IN 


DISP. 5 LIM. 


PRTY OF CHAPPED 


TCB 




STORE TCB ADDR 

IN LAST SLOT IN 

TSCE 



PLACE SUBJ TCB 

ON QUEUE SEARCH 

TCB QUE FOR 

HIGHER PRI 

READY TASK 



TASK SWITCH 




PLACE ADDR OF 

HIGHER PRI TCB 

IN 'NEW PNTR 







( TYPE 1 EXIT J 




STORE TCB ADDR 

IN 1ST AND NEXT 

SLOT IN TSCE 
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Chart BC, Chap Routine — with Time-Slicing (Page 2 of 3) 




MAKE 1ST SLOT= 

LAST SLOT IN 

TSCE 



©- 



FIND TCB IN 

READY QUEUE 

WITH TCBTCB= 

TSCE LAST 



ZERO 1ST NEXT 

AND LAST SLOTS 

IN TSCE 



I— ►roT 



B 



MOVE NEXT TCB 

ON READY QUEUE 

TO TSCE 







MOVE TCBTCB FLD 

OF CHAPPED TCB 

TO NEXT SLOT IN 

TSCE 



L 



STORE THIS TCB 

ADDRESS AS TSCE 

LAST 



L 



U18 



Chart BC. Chap Routine — with Time Sharing Option (Page 3 of 3) 



1 



ADD CHAP VALUE 

TO TS 

DISPATCHING 

PRIORITY 




© 



MOVE 1ST USER 

TS DISP PRI TO 

CHAPPED TCB TS 

DISP PRI 



1. 



QUEUE CHAPPED 
TCB ON TCB 
READY QUEUE 




LOAD PTR TO 

NEXT TS USER'S 

TCB ON READY 

QUEUE 



ZERO TS 
DISPATCHING 
PRIORITY OF 
CHAPPED TCB 



L 







STORE RESULT IN 

TS DISPATCHING 

PRIORITY OF 

CHAPPED TCB 



MAKE CHAPPED 

TCB TS LIMIT 

AND TS DISP. 

PRIOR. = TS 

LIMIT 



©- 



GET FIRST TCB 
OF USER 
SUBGROUP 



UPDATE LIMIT 
PRIORITY OF 
CHAPPED TCB 





NO 

1 


^<^HAPPED TCB\ 
Q= USER'S LAST> 


\ 






J 




UPDATE USER'S 

LAST PTR WITH 

OLD PREVIOUS 

TCB PTR 




► 

J. 



UPDATE USER 

LAST PTR WITH 

CHAPPED TCB PTR 




ADJUST TS 

DISPATCHING 

PRIORITY OF 

LOWER USER 

TASKS 




TASK SWITCH 



PLACE ADDR OF 

HIGHER PRI TCB 

IN 'NEW' PNTR 



►■( TYPE 1 EXIT I 



■0 
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Chart BD. Extract Routine 



lEAQTBOO 



lEAQTBOO 



r~ ^ (^ ^ 

( EXTRACT \ K EXTRACT j 



BRANCH ENTRY 




L 




© 



►■( ABTERM \ 

© 




,1. 



DETERMINE 

FIELDS TO BE 

EXTRACTED 



PLACE EXTRACTED 
FIELDS INTO 
OUTPUT LIST 



VALID. CHK RTN 



^-G3 ^^ 

( TYPE 1 EXIT I 



VALID. CHK RTN 



VALIDATE FIRST 

OUTPUT LIST 

ADDRESS 



VALID. CHK RTN 



VALIDATE LAST 

OUTPUT LIST 

ADDRESS 
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Chart BE. Detach Routine 



r' ^ 

( DETACH j 



IGC062 f lEAOVLOl DTERROR 
VAL. CHECK 





REMOVE TCB OF 

SUBTASK FROM 

QUEUE OF PARENT 




72-BYTE SAVE 

AREA FROM 

SUBPOOL 250 



192-BYTE TCB 

FROM SUBPOOL 

253 



G 



J 






RESET 
STOP/START 
NONDIS PATCH 

FLAG 



SAVE SUBTASK 

ECB ADDRESS IN 

SVRB 



STORE ADDRESS 

OF NEW ECB IN 

SUBTASK TCB 



WAIT FOR 

SUBTASK 

TERMINATION 




CLEAR IDE ADDR. 

LOAD ERROR CODE 

33E. RESET 

STOP/START 

NONDISP. FLAG 



© 




IQE 



" IGC005(S} 



FREEMAIN DA 



L 



" IGC005(S1 







FREEMAIN DA 



L 



© 



FSTIME ■' lEAOABOO 

— D^ 

ABTERM 




RESET PRIMARY 

NONDISPATCH 

FLAG 



SCNDTIME I lEAOABOO 
ABTERM 



r' ^ 

( EXIT j 



RESET PRIMARY 

NONDISPATCH 

FLAG 




L 



© 
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Chart BF. SPIE Routine 



lEAQTBOO 



( ^ 

( SPIE J 



-B2- 



OBTAIN POINTER 
TO PROGRAM 
INTERRUPTION 
ELEMENT (PIE) 
FROM CURR TCB 






IGCOOa 








„. 


NO 


GETMAIN DA 




INITIALIZE PIE 
TO ZERO 




PLACE ADDRESS 
OF PIE INTO 
CURRENT TCB 


GET SPACE FOR 

PIE. 32 BYTES, 

SP 250 









NOTE-THIS ADDRESS WILL 
BE ZERO FOR THE 
FIRST EXECUTION OF 
SPIE. 



OBTAIN AND SAVE 

ADDR OF OLD 

PROGRAM INTRPTN 

CONTROL AREA 

(PICA) 



-D5- 



SAVE CURRENT 
PROG MASK FIELD 
FROM RB OLD PSW 
IN TCBPIE FIELD 
OF CURRENT TCB 



L 







PLACE ADDRESS 

OF NEW PICA 

INTO PIE 



PLACE ADDRESS 
OF OLD PICA 
INTO REG 1 







ZERO PROGRAM 

MASK FIELD IN 

OLD PSW 




RESTORE PROG 

MASK FIELD FROM 

TCBPIE FIELD OF 

CURRENT TCB 



STORE NEW PICA 

MASK IN PROG 

MASK FIELD OF 

RB OLD PSW 



c 



~) 
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chart BG. Wait Routine (Page 1 of 2) 



IEAQSY50 



r' ^ 

( WAIT \ 



-Bl- 



SET SYSTEM MASK 
OF OLD PSW TO 

ENABLE I/O AND 

EXTERNAL 

INTERRUPTIONS 





J 




DECREMENT RB 

WAIT COUNT BY 

ONE 




J2— 

PLACE 


WAIT 




SET WAIT 

PENDING FLAG IN 

CURRENT RB 


CURRENT RB 










..^ 


'v 



ZERO RB SEARCH 

FLAG, CLEAR 
WAIT FLAGS OF 
UNPOSTED ECBS 



-K2- 



SET 'NEW' TCB 

PTR TO ZERO; 

PLACE WAIT 

COUNT 

INTOCURRENT RB 
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Chart BG. Wait Routine — with Job Step Timing (Page 2 of 2) 




TASK SELECT 



SELECT TASK 
STARTING WITH 
JOB STEP TCB 




DEQUEUE 




REMOVE THE TQE 

FROM TIMERS 

QUEUE 




' ■ 




SAVE THE CPU 











INSERT THE TQE 

ON THE TIMER 
QUEUE 



0^ 

r~' — ^ 

( TYPE 1 EXIT I 



OBTAIN TCT ADDR 

FROM INITIATOR 

TCB 




PLACE WAIT TIME 

LIMIT FROM TCT 

INTO TQE 



^2U 



Chart BH- Post Routine (Page 1 of 2) 



IEAQSY50 



NO 


VALID. CHK RTN 




RESET RB'S 

SEARCH FLAG, 

RESET ECB'S 

WAIT FLAGS 


VALIDATE ECB 
ADDRESSES 
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Chart BH, Post Routine — with Job Step Timing (Page 2 of 2) 





, -_ THERE .... , 
INITIATOR TQE_^ 




REMOVE THE TO 
FROM THE TIME 
QUEUE 



REPLACE CPU 

TASK TIME IN 

TQE 



Ui 



B 
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Chart BI, ENQ Routine (Page 1 of 2) 



SHARED DASD 



IEAQENQ2 





ENQ^ 


ENQ ^> 


?ESE 
"1 


*VE 


t 


V 




01 
A3) 


02 
A5 
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Chart BI. ENQ Routine (Page 2 of 2) 



A I 

^" ^ 

f ABENDO j 




i EXIT t-* 



1 



CREATE A QEL 



PREPARE SVRB 

FOR RESERVE 

RESTART 



L. 



© 



r 



i 



DO 'SET MUST 
COMPLETE ' 

PROCESSING IF 
NECESSARY 





ENQWAIT 



f DISPATCHER J 



SHARED DASD 




INSERT UCB ADDR 
INTO QEL, SET 
RESERVE FLAG, 
INCREMENT UCB 
RESERVE COUNT 



L 



© 
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Chart BJ, DEQ Routine — with Time Sharing Option (Page 1 of 2) 



IEAQENQ2 





PROCMIN 




Section 13: Charts 429 



Chart BJ. DEQ Routine — with Shared DASD (Page 2 of 2) 







FOR lOB, DCB, 

ECB, DEB, CCW, 

AVT 



INITIALIZE lOB, 

DCB, ECB, DEB, 

CCW, AVT 



WAIT FOR 

COMPLETION OF 

I/O 



FOR lOB, DCB, 

ECB, DEB, CCW, 

AVT 



^B 
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Chart BK, Stage 1 Exit Effector 



lEAQEFOO 

\» A2- 

'^ STAGE 1 EXIT 



y — ^^ N. 

/STAGE 1 EXIT \ 
( EFFECTOR \ 



GET SPACE FOR 
INTERRUPTION 
REQ BLK IRB 




GET SPACE FOR 

PP REG SAVE 

AREA 



INITIALIZE IRB 
PER CIRB 
OPERANDS 



G 



3 
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Chart BL. Stage 2 Exit Effector 



lEAQ NUOO 

^STAGE 2 EXIT 




RECOMPLEMENT 

ADDRESS OF 

ELEMENT 



BYTE LINK ADDR} 

ON ASYNCHRONOUS 

QUEUE 



QUEUE ELEMENT 

(4BYTE LINK 

ADDR) ON 

ASYNCHRONOUS 

QUEUE 



EFEXIT 

/ TURN ON 
/ STAGE 3 



< SWITCH 
■lEAODSOl ) 
"ISPATCHER 



\(IEAi 

\dis 



C-E. 
RE' 
1 



3 
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Chart BM. Stage 3 Exit Effector (Page 1 of 2) 







lEAQNUOO 

'"stage 



X ^ftl S. 

f STAGE 3 EXIT A 
( EFFECTOR j 



RESET STAGE 3 

SWITCH 

(IEA0DS01 ) 






YES 


0. 



i 



SET STAGE 3 

SWITCH 
(IEA0DS01) 




NOTE: 
RB OLD PSW IS 
SET TO ENTER 
ERROR FETCH 
SEQUENCE AT 
ERFETCH (02/A3) 
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chart BM. Stage 3 Exit Effector (Page 2 of 2) 



f ENTRY \ 



FROM AN 
I/O ERROR 
ROUTINE 



DEVELOP ERROR 

RTN NAME FROM 

CODE IN REG 13 



PLACE NAME INTO 

SIRB AND SET 

PSW TO ENTER 

ERFETCH 



f Di; 



DISPATCHER 



3 




PLACE ENTRY 
POINT ADDRESS 
INTO OLD PSW 
FIELD OF SIRB 



OBTAIN ENTRY 
POINT NAME OF 
ERROR ROUTINE 



PROG FETCH 



^X^DETERMINE^N. I/O ERROR 
^YPE OF ERROR^-— -] 


\ 


Xno i/o/ \ 

ERROR 1 03 ) 
FOUND \^_y 


El " 




SET UP ERROR 
CODE (806) 






' ' IEA0AB01 



G 



3 



NOTE-- 

REENTRY AT ERFETCH 
WILL OCCUR WHEN 
OPERATOR PRESSES 
RESET AND START KEYS 
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caiart BN. Task Switching Routine — Uniprocessing 



USE TCB ADDR IN 

OLD TCB PNTR 

(lEATCBPSa) FOR 

TEST 




NOTE- THE SUBJECT TASK IS 
REPRESENTED BY THE 
TCB WHOSE ADDRESS IS 
PASSED TO THIS ROUTINE. 



SEARCH DOWN TCB 

QUEUE, STARTING 

WITH CURRENT 

TCB 




INDICATE TASK 

SWITCH TO 
SUBJECT TASK 
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Chart BO. Task Switching Routine — Multiprocessing 



lEAQNUOO 




436 



chart BP. STAE Service Routine 



r' ^ 

I STAE I 




L 







-FA- 



PLACE NEW SCB 

ON QUEUE: STAI 

SCB IS PLACED 

ON TOP OF 
SUBTASK TCB Q 



STORE EXIT AND 

PARAMETER LIST 

ADDRESSES IN 

SCB 



REMOVE SCB FROM 

QUEUE. MOVE 

PREVIOUS SCB 

ADDRESS AND 

FLAG BYTE 



CANCELLED SCB 



SET XCTL AND 

STAI FLAGS AS 

INDICATED BY 

OPTIONS 



► ( EXIT \-* 







STAE SCB QUEUING: 

THE NEW SCB IS PLACED 
BEFORE FIRST STAE SCB. 
IF A STAI SCB PRECEDES 
THE FIRST STAE SCB, 
THE NEW SCB IS PLACED 
BEFORE THE FIRST STAE 
SCB BUT AFTER THE 
LAST STAI SCB. 
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Chart BQ. ABEND/STAE Interface Routine (ASIRO) (Page 1 of 2) 



lEAQTMOR 



r' ^ 

I ASIRO j 




' ' RHBRANCH 




SET STAE 

RECURSION BIT 

AND GET CURRENT 

SCB 




GET NEXT SCB 

AND SET 

RECURSION STAE 

FLAG 



' ' RMBRANCH 




©3. 

NOTSTAI ^v^^^ 


NO 








y^ \S STAE^S. 
C USER IN P/P Z 
^^^ MODE \/^ 




INDICATE 
SUPERVISOR MODE 






^\ 


XYES 








RBTEST 










GET ADDR OF 
ABENDING RB 






GET COM? CODE 

AND ADDR OF 

LOAD ZERO 



INDICATE XCTL 

FROM ASIRO AND 

SET PARAM FOR 

XCTL 



c 



3 
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Chart BQ. ABEND/STAE Interface Routine (ASIRO) (Page 2 of 2) 
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Chart BR. ABEND/STAE Interface 1 Routine (ASIRl) (Page 1 of 2) 



lEAQTMOS 




START TO 

INITIALIZE WORK 

AREA 




HOVE REGS AT 

ABEND TO WORK 

AREA AND GET 

ABENDING KB 




r 




IND PGM NAME 

NOT FOUND AND 

PUT EP IN 

PARAMLIST 



PUT RB ADDR OF 

ABENDING PGM IN 

WORK AREA AND 

ZERO 3 WORDS 










~L 




MOVE NAME OF 
ABENDING PGM TO 

WORK AREA AND 
GET ABENDING RB 




MOVE ENTRY 

POINT ADDR OF 

ABENDING PGM IN 

WORK AREA 



-FA- 



ZERO LAST WORD 
IN WORK AREA 

AND SAVE ENTRY 

POINT AND PGM 

NAME 




440 



Chart BR. ABEND/STAE Interface 1 Routine (ASIRl) (Page 2 of 2) 
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Chart BS. ABEND/STAE Interface 2 Routine (ASIR2) 



lEAQTMOT 



f ASIR2 \ 








REGISTER SAVE 

AREA OF WORK 

AREA 




INDICATE NO 

STAE PROCESSING 

ALLOWED 



G 



J 




SET RB OLD PSW 

■ TO ADDR OF SVC 

13 INSTRUCTION 



n^ — ^ 

f EXIT j 



442 



Chart BT. ABEND/STAE Interface 3 Routine (AS1R3) (Page 1 of 3) 



f ASIR3 I 




LOCATE 1ST PGM 

SEGMENT ' S 

BOUNDS 



L 



© 



r~^' ^ 

{ ASIR4 j 






\ 


^0 


Qi,y-*- 




NXTDEB 






GET NEXT DEB 
(IF ANY) 



CLO SE 

CLOSE 




r 





YES y^ ALL DEBS 

PROCESSED FOR, 
THIS RB 



U 



© 



GET NEXT DEB 
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Chart BT. ABEND/STAE Interface 3 Routine (ASIR3) (Page 2 of 3) 



READY TO FREE 

FROM PREFIX OF 

ORDINARY DEB 





SET INDEX TO 
lOB PTR FIELD 
GET I OB ADDR 



VES 


TURN ON FLAG IN 

TCBNSTAE 

INDICATING ONE 

lOB/DCB 






c- " 




GET lOB FROM 

DCB BUMP PAST 

PREFIX 



READY TO FREE 

FROM PREFIX OF 

QTAM DEB 



1 





TAKE lOB FROM 

DCB OFF RESTORE 

CHAIN 



^B 



B 



SELECT NEXT JOB 

OFF RESTORE 

CHAIN 



Li 



B 



^^'^ 



Chart BT. ABEND/STAE Interface 3 Routine (ASIR3) (Page 3 of 3) 





SET INTERNAL 

FLAG INDICATE 

NO I/O 

RESTORABLE 



^f^ 



REMOVE FIRST 

IDE FROM 
RESTORE CHAIN 




NEXT IOB= 

CURRENT lOB 

ADDR + INDEX 



TURN OFF FLAG 

IN TCBNSTAE 

INDICATING ONE 

lOB/DCB 
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Chart BU. ABEND/STAE Interface 4 Routine (ASIR4) (Page 1 of 4) 



lEAQTMOV 




NO 


EXTRACT 


GET NEXT 
SEGMENT BOUNDS 





L 







CiTFIX 
^^5 . 

( ENTRY 1 



ADJUST PTR TO 
BYPASS PREFIX, 
AND GET MID PTR 



GET SEGMENT 

UPPER AND LOWER 

BOUNDS 



^_K5-i 

/ RETURN TO \ 
I CALLER 1 



446 



Chart BU. ABEND/STAE Interface H Routine (ASIR4) (Page 2 of H) 




r 
© 





READY TO FREE 

FROM PREFIX OF 

ORDINARY DEB 





GET NEXT DEB 



L 







y^ „„„ \ 


NO 










^ 


■Xyes 




NOQTAM ^ ■ 






ADJUST POINTERS 






FREEMAIN 


DA 














FREE 


DEB 



L 
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Chart BU. ABEND/STAE Interface 4 Routine (ASIR4) (Page 3 of 4) 




GET SIZE OF 
lOBS AND THEIR 
ADDR FROM DCB 



LOCATE LCB 







lOBPROC 


DEO lOB FROM 
RESTORE CHAIN 
IF NECESSARY 


J 










GET FIRST lOB 
ADDR 



GET SIZE OF 

■EXTENTS CLEAR 

COUNT AND GET 

EXTENT NO 



L 




DEO lOB FROM 
RESTORE CHAIN 
IF NECESSARY 



DEQ lOB FROM 
RESTORE CHAIN 
IF NECESSARY 



DEQ I OB FROM 
RESTORE CHAIN 
IF NECESSARY 



GET NEXT LCB 



READY RETURN 

ADDR FOR CLOSE 

PROCESSING 



Li 



E> 



HH8 



Chaart BU. ABEND/STAE Interface 4 Routine (ASIR4) (Page U of 4) 



GET EXTENT SIZE 

CLEAR COUNTER 
AND GET EXTENT 




> GET UCB ADDRESS 




REMOVE SENSE 

INFO AND GET 

I OB ADDR 



L 




( ENTRY \ 



CLEAR OLD lOB 
REG AND GET 1ST 
lOB FROM CHAIN 
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Chart BV- ABEND/STAE Interface 5 Routine (ASIR5) 



lEAQTMOW 



r~ ^ 

f ASIR5 j 





NO 


GETMAIN DA 


RETRY PRE 





READY TO USE 

SCB'S RB FOR 

RETRY RB 



INITIALIZE PRB 

WITH PROTECT 

KEY OF TCB 



TURN OFF ABDUMP 
NONDISPATCH- 
ABILITY FLAG 




FIND MOST 

RECENT PRB ON 

CHAIN 




■E3- 



SET RETURN REG 

IN RB SAVE AREA 

TO SVC 3 SET 

OLD PSW TO 

RETRY 



L 



© 



SET PSW OF 

RETRY RB TO 

ADDR OF RETRY 

ROUTINE 



POINT RB OLD 

PSW TO SVC 3 

INSTRUCTION IN 

CVT 







1 



INITIALIZE 

REGISTERS IN 

PLACE OF WORK 

AREA 




PLACE NEW PRB 

AFTER ABEND'S 

SVRB ON RB 

QUEUE 



ALLOW 

ASYNCHRONOUS 

INTERRUPTS 





ERASE INFO LIST 

ELEMENTS FOR 

THIS TASK 



RESET ALL REC 

EXCEPT STAE 6 

XCTL RESTORE 

REGS 1 £ 2 




G 



3 



REINITIALIZE 

ALL BUT FIRST 

WORD OF WORK 

AREA 



L 
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Chart BW. Set Status Service Routine (Page 1 of 2) 




MULTIPLY CODE 

PASSED BY a TO 

GET BRANCH 

TABLE INDEX 



n 


> C3 


1 


>02A1 


■> 


>02A3 


1 


>02E2 


4 


>02A5 


s 


>02J1 


h 


>02Di| 


7 


>02D5 





IEA0AB01 


NO 


ABTERM LF 




ERROR CODE = 









f RETURN \ 



GET JOB STEP 

TCB OF CURRENT 

TCB 




INCREMENT 

NONROLLOUTABLE 

COUNT 



•-f RETURN 1 



DECREMENT 

NONROLLOUTABLE 

COUNT 






GETIQE 



OBTAIN IQE 



STG2 EX EFF BL 



3 
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chart BW. Set Status Service Routine (Page 2 of 2) 




-A2- 



CLEAR MUST 
COMPLETE FLAG 

ALLOW 
ASYNCHRONOUS 

EXITS 



CLEAR MUST 

COMPLETE FLAG, 

ALLOW 

ASYNCHRONOUS 

EXITS 



SET MUST 
COMPLETE AND 

PREVENT 

ASYNCHRONOUS 

EXIT FLAGS 



-B2- 



CLEAR 

NONDISPATCHABLE 

FLAGS IN STEP 

TASKS EXCEPT 

CURRENT TCB 



Cl- 



NONDISPATCHABLE 
FLAG IN ALL 

STEP TASKS EXC 
CURRENT TCB 



TASK SWITCH BN 



DETERMINE IF 

TASK SWITCH IS 

NECESSARY 




SET MASK. START 

LOOP AT TCB 

AFTER MASTER 

SCHED . 



SET MUST 
COMPLETE AND 

PREVENT 

ASYNCHRONOUS 

EXIT FLAGS 



r; 







NONDISPATCHABLE 

MASK IN ALL 

TASKS EXCEPT 

CURRENT TCB 




CLEAR 

NONDISPATCHABLE 

MASK IN ALL 

TASKS EXCEPT 

CURRENT TCB 



TASK SWITCH BN 



DETERMINE IF 

TASK SWITCH IS 

NECESSARY 



E> 



1 



SET STOP 

INDICATOR AND 

NONDISPATCH 

MASK 



1 



SET START 
INDICATOR AND 
DISPATCH MASK 




U 









NOSVRB 






SET STOP AND 

PRIMARY 

NONDISPATCHABLE 

FLAGS 


NO 




SET 


^0 

JCPLT 



INDICATE EXIT 

TO SET STOP NGN 

DISPATCH FLAG 

WHEN SVRB 

COMPLETES 



CLEAR 

START/STOP 

NONDISPATCHABLE 

FLAGS 



DECREMENT 

START/STOP 

COUNT 




452 



Chart CA. Link, Load, XCTL, and SYNCH Processing (Page 1 of 3) 



lEAQCSOl 
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Chart CA. Link, Load, XCTL, and SYNCH Processing (Page 2 of 3) 




H5H 



chart CA. Link, Load, XCTL, and SYNCH Processing (Page 3 of 3) 



FROM SVC SLIH (CHART AB) 
WHEN LOAD MACRO INSTRUCTION 
IS ISSUED 





SAVE REFRESH 

INFO IN 
CALLER'S SVRB 



TA AVAIL. CHK AD 



FIND AVAILABLE 

TRANSIENT AREA 

BLOCK (TAB) 



INCREMENT 

TRANSIENT AREA 

USER COUNT 




-MS- 



MAKE SVRB WAIT. 

PUT SVRB ON REC 

A. PT RBOPSW TC 

TAXRETRY. SET 

UP TASK SW. 




SET INTO WAIT 

CONDITION ALL 

SVRB'S ON TAB'S 

USER QUEUE 



( Dis: 



DISPATCHER 



) 



-K2- 



MAKE CALLER'S 
SVRB WAIT. SET 

PSH FOR ENTRY 
TO TAB FROM 
DISPATCHER 



EP=IEAODS 

CHART KF-- (REENTRY 
WILL OCCUR LATER AT 
TAXRETRY, BLOCK F2) 



QUEUE CALLER'S 
SVRB ON USER 
QUEUE FOR TAB 



SET UP TASK 

SWITCH TO TA 

FETCH TASK AT 

TAHFETCH CHART 

AEFl 



SET UP TASK 

SWITCH TO TA 

FETCH TASK AT 

TABLDL 



TURN ON 

'LOADING' 

INDICATOR IN 

TACT ENTRY 



SEE CHART AE 



INCREMENT 

TRANSIENT AREA 

USER COUNT 



( Dis: 



) 



L 



© 
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Chart CB. Identify Routine (Page 1 of 2) 



lEAQIDOO 






QUEUE SEARCH 





MINLSQ5 



GET 24 BYTES 

FOR CDE IN 

SP255 OR SP245 



NLC FIELDS OF 
CDE 



queue minor cde 
Shead of major 

CDE 



f EXIT J 



QUEUE SEARCH 








,1 



■c 



3 



GET SPACE FOR 

CDE AND EXTENT 

LIST IN SP255 



INITIALIZE SPZ, 

NLR, XLE FIELDS 

OF CDE 



QUEUE MAJOR CDE 

ON CALLER'S 

JPAQ 
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Chart CB. Identify Routine (Page 2 of 2) 



f NOMIN \ f CONTSRCH ) 



SET UP TO 

SEARCH JPACQ 

FOR DUPLICATE 

NAME 



SEARCH QUEUE 



SET UP TO 

SEARCH EXTENT 

LIST FOR 

DUPLICATE NAME 



SEARCH QUEUE 



r~ ^ 

I RETURN j 
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chart CC. Delete Routine 




r^* ^ 

( EXIT 1 



DECREMENT 

RESPONSE COUNT 

IN LOAD LIST 

ELEMENT (LLE) 




REMOVE LLE FROM 

LIST AND FREE 

SPACE IT 

OCCUPIED 



DECREMENT USE/ 
RESP COUNT IN 

MAJOR CONTENTS 

DIRCTY ENTRY 

CCDE) 




TURN OFF 
REENTRANT AND 
REUSABLE BITS 



IF NO OTHER 
REQ'S FOR MODULE, 
EITHER PURGE 
MODULE OR FLAG 
JPACQ FOR OPTIONAL 
MODULE RELEASE 
BY GETMAIN RTN. 



DETERMINE IF 
MODULE IS 
REUSABLE 
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chart CD. Program Fetch Routine (Page 1 of 3) 







r' ^ r~ ^ 

I PROGRAM FETCH 1 I ENTRY j 



FROM LINK, 
LOAD XCTL, 
AND SYNCH 
PROCESSING 
ROUTINE 
CHART CA 



RECEIVE PARAMS 

INCL SUBPOOL ID 

FOR PP SPACE 

AND PDS ENTRY 

ADDR 



-B2- 



FROM OVERLAY 
SUPERVISOR 
CHART CE 



-.i 



CALCULATE 

LENGTH OF EXT. 

LIST AND PLACE 

IT IN EXTENT 

LIST 



r' — ^ 

f ENTRY 1 



RECEIVE PARAMS 

INCL NOTE LIST 

AND NUMBER OF 

SEGMENT TO BE 

LOADED 



i 



FROM TRANS 
AREA FETCH RTN 
CHART AE 
OR STAGE 3 
EXIT EFFECTOR 
CHART BM 



LOCATE ADDR OF 
EMPTY RLD BFR 
AND CHAN PROG 



-Ba- 



CALC CTL SECT 

LENGTHS, USING 

LIST OF ORDERED 

ORIGINS IN SCAT 

LIST 



-B5- 



CONVERT 
RELATIVE DISK 

ADDRESS TO 
ABSOLUTE DISK 

ADDRESS 



C1- 



INITIALIZE I/O 

CONTROL BLOCKS, 

CHAN PROGRAMS, 

AND FETCH 

BUFFER TABLE 




RESET BUFFER 

TABLE POINTER. 

RESET CHAN PROG 

FOR RESTART 



PLACE CNT SECT 
LENGTHS IN 
EXTENT LIST 



EXCP SUPERVISOR 



INITIATE I/O 



OBTAIN ADDR FOR 
MODULE AND GET 
TTR OF SEGMENT 
FROM NOTE LIST 



GET SPACE FOR 

BLK EXT LST 6 

INTL2 EXT LIST 

FROM PDS DIRCTY 

ENTRY 




NO 


GETMAIN DA 


OBTAIN BLOCK OF 

SPACE FOR 

MODULE 





GET TTR OF 
FIRST TEXT RCD 

FROM PDS 
DIRECTORY ENTRY 







w lECXCP(S) 



EXCP SUPVSR 



w IGC004(S) 



GET NEEDED 

STORAGE AREAS 

FOR MODULE 



'' IGCOOl (S) 



0- 




FROM ALLOC ADDR 

(GETMAIN) AND 

SCAT/TRANS TBL, 

CALC EACH CONT 

SECT ADDRESS 



FREE SPACE FOR 
BLK EXTNT LIST. 

CALC SIZE OF 
SCAT/TRANS TBL 




PLACE RELOC'D 
CONT SECT ADDRS 
IN SCATTER LIST 



C-F 
RE' 



J 



U 











1 



COMPUTE 
RELOCATION 
FACTOR FOR 
ENTRY POINT 



CHECK IF ALL 

I/O HAS BEEN 

COMPLETED, I" 

NOT, WAIT 



-Kl- 



GET TTR OF 
SCAT/TRANS TBL 
FROM PDS DIRCTY 
AND READ (EXCP) 
SCAT/TRANS TBL 



L 







BRANCH APPLIES 
TO MAIN STORAGE 
HIERARCHY SUPPORT 




J 



■K5- 



FOR ANV TVPE 

MOD, SET COMPL 

CODE, CALCULATE 

RELOC ENTRV 

POINT ADDR 
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Chart CD. Program Fetch Routine — PCI and Channel End Appendages (Page 2 of 3) 



PCI APPENDAGE 
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Chart CD. Program Fetch Routine — with Main Storage Hierarchies (Page 3 of 3) 




NO 


GETMAIN DA 


OBTAIN SPACE 

FROM SPECIFIED 

HIERARCHY 





L 



© 



GET SCAT TRANS 

TBL FROM PDS 

DIR, AND READ 

(EXCP) 

SCAT/TRANS TBLC 





GET SPACE FOR 

SCATTER EXTENT 

LIST 



GETMAIN DA 



GET SPACE FOR 

BLOCK EXTENT 
LIST 



-Fa- 



CALCULATE CSECT 
LENGTHS USING 

LIST OF ORDERED 

ORIGINS IN 

SCATTER LIST 



^B 



GET SPACE IN 

EACH REQUIRED 

HIERARCHY 



I— »-roT 



B 
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Chart CE. Overlay Supervision 



MEANS REPEATED 
BRANCHES TO SUBROUTINE 
DURING LOOP PROCESSING 



r~" ^ 

( ENTRY j 

FROM SVC SLIH 
-CHART AB- WHEN 
BRANCH INSTRUCTION 
OR CALL MACRO 
INSTRUCTION IS ISSUED 



C037 

( ENTRY j 

FROM SVC SLIH 
-CHART AB- WHEN 
SEGLD OR SEGWT 
MACRO INSTRUCTION 
IS ISSUED 



-B2- 



SENT INDR FOR 

SEGLD/ SEGWT . 

CHK IF ADCON 

ENTRY IN ENTAB 

IS COMPLETE 



-B3- 




EXTRACT ADDR OF 
CURR SVRB, ADDR 
OF SEGTAB, AND 
NUMBER OF REQ'S 
SEGMENT 



^B5 ^^ 

►^1 EXIT 1 



( EXIT J 



RESIDENT OVERLAY SUPERVISOR MODULE 



NON-RESIDENT OVERLAY SUPERVISOR MODULE 



RETURN IF THIS 
SEG IS BEING 

LOADED AND THIS 

REQUEST IS A 

SEGLD 











If A SEGLD IS 


IN PROGRESS, 


WAIT 




FROM 

DISPATCHER 
CHART KGJl 
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Chart DA. GETMAIN/FREEMAIN Routine (Page 1 of 3) 



QMBRANCH 




G2KSRCH 


SPACE 


GDQEBLD 


LOCATE 2K 

BLOCKS TO 

SATISFY REg 


BUILD DOE FOR 
BLOCKS 


AVAIL 




NO SPAC 
AVAIL 














..J 


\ 


GSB 


>^ .,. 





REMOVE 

ALLOCATED QUEUE 

ELEMENT (AQE) 

FOR AREA FROM 

AQE QUEUE 




PURGE PROGS NO 

LONGER NEEDED 

BY JOB STEP 





1 H3— 

SET ST 

KEY 
ASSIG 

BLO 


rORAGE 
I OF 
>JED 2K 

:ks 








s^ 


IF 










GMSMFCRE DA2A1 


- 


SMF STORAGE 
SUBROUTINE 









GET STORAGE TO 

BE ALLOCATED 

FROM ASSIGNED 

2K BLOCKS 



L 









U 



© 



ADD FREE QUEUE 

ELEMENT (FQE) 

FOR AREA TO FQI 

QUEUE, COMBINE 

FQE'S IF POSS 




REMOVE 2K 

BLOCKS FROM 

SUBPOOL, SET 

STOR KEYS OF 

FRE BLKS TO SUP 



FMSMFCRE DA3A1 



U 
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Chart DA, GETMAIN/FKEEMAIN — SMF Storage Routine (Page 2 of 3) 




INITIALIZE PTRS 

TO TCT STORAGE 

AREA 




ADJUST STORAGE 

AREA POINTERS 

TO LCS AREA 




CONVERT REQ 

INTO 2K BLOCKS, 

ADD TO CURRENT 

2K BLOCKS IN 

TCT 




-F2- 



DEVELOP HIGH 

AND LOW 

ADDRESSES 

ALLOCATED FOR 
THE REQ 
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Chart DA. GETMAIN/FREEMAIN — SMF Storage Routine (Page 3 of 3) 



bMtUKt 

y '^l S. 

/SMF FREEMAIN \ 
i SUBROUTINE 1 




r~"' ^ 

f RETURN j 



[ RETURN j 



n1^ 


\ 


\YES 






^ LCS REQ 


ADJUST STORAGE 

AREA POINTERS 

TO LCS AREA 




y * 


1 






•4 ' APPLICAEL 



APPLICABLE ONLY IN SYSTEMS WITH ROLLOUT 




-E2- 



CONVERT REQ 

INTO 2K BLOCKS, 

SUBTRACT FROM 

CURRENT 2K 
BLOCKS IN TCT 



••( RETURN I 



-Fl- 



DEVELOP HIGH 

AND LOW 

ADDRESSES 

ALLOCATED FOR 

THE REQUEST 




r~'' ^ 

( RETURN J 



r~ ^ 

i RETURN j 
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Chart DB, GETPART/FREEPART Routine (Page 1 of 2) 



C-Al s. 
GETPART/ A 
FREE PART j 



FROM 

GETMAIN/FREEMAIN 
CHART DA 



SET ONE DONE 

SW, GET NEXT 

ADDR REQ. ENTRY 

IN LIST, 

DETERM. HIER. 




FBQSRCH 



FIND ADDR OF 

FIRST AVAIL 

BLOCK 



0- 



BUILD PQE, 

ADJUST PQE AND 

FBQE POINTERS 



0- 




GET 8 BYTES IN 
SP 252 IF 
NECESSARY 



C RETURN TO \ 
CALLER j 

RETURN CODE=04 





SET INITIATORS 

WAITING FOR 

REGION 

DISPATCHABLE 




ASSIGN AREA TO 

TASK, ADJUST 

FBQES 



L 







: 'RETURN CODE=00 
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chart DB. GETPART/FREEPART Routine (Page 2 of 2) 




TASK SWITCH 



SET WAIT OFF IN 
TCB, SEE IF 
TASK SW REQ 



SET INITIATORS 
WAITING FOR A 

REGION 
DISPATCH ABLE 




VARY STOR OFFL 



LOGICALLY REMVE 

REGION FROM SYS 

IF VQE EXISTS 
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Chart DC. Rollout-Rollin Criterion Routine (Page 1 of 2) 




© 



i 



TERMINATE THE 

TASK SPECIFIED 

BY IEAQAPG3 



TRY TO FILL RE- 
QUEST FROM UN- 
RSSIGNED STRGE 



0- 



IEAQPG1 



COINCIDENT 

ROLLOUT 

APPENDAGE 



RR002 
ROLLOUT 
NOT 
ALLOWED 



DEQUEUE IQE 
FROM IRB AHD 
ENQUEUE IT IN 



SET UP ADDRESS 

OF TCB TO 

ENSURE TASK 

SWITCH 



»-f EXIT J 




,1 



INITIALIZE AND 

ENQUEUE PQE. 

SET ROLLOUT 

INDICATORS 



~1 



FIND STEP AND 

REGION ELIGIBLE 

FOR ROLLOUT 






NO 


RSTRIO DF 


RESTORE I/O RE- 
QUESTS FOR EACH 
^TASK IN STEP 





BUILD AND 

INITIALIZE A 

NEW PQE 



TEST REGIONS OF 

STEP AGAINST RO 

CRITERIA 



RESET/MOVE WTOR 

REPLIES FOR 

STEP'S TASKS 




SET STEP TO BE 

ROLLED OUT NON- 

DISPATCHABLE 

(TCBFRO) 



SET STORAGE 

PROTECT KEY OF 

BORROWED REGION 

TO ZERO 



U 








RESET STEP 

DISPATCHABLE 

(TCBFRO) 



L 







QUIESCE I/O AND 
PURGE MESSAGE 

REPLIES FOR 

EACH TASK IN 

STEP 



TERMINATE THE 

TASK REQUESTING 

ROLLOUT 



ROLLOUT SPECI- 
FIED REGION 
(PQE ADDRESS) 



L 
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Chart DC- Rollout-Rollin Criterion Routine (Page 2 of 2) 



NOTE-PQE 

ADDRESS IS PASSED 
IN COMPLEMENT 
FORM AS INPUT 
PARAMETER 



RETEXIT 






GET NEXT AVAIL. 

lOE FROM ROLL- 
OUT IRB, MAKE 
SPECIFIfiD IQE 
THE NEXT IQE 



SET UP ADDRESS 

OF TCB TO 

INSURE TASK 

SWITCH 



Ci 




SET PQE ' USE 

STATUS ' 

REGISTER 



ROLLIN 

SPECIFIED 

REGION 



L 



3 



EXIT FROM ROLLOUT/ 
ROLLIN RESULTS IN 
THE ROLLOUT TASK 
BEING PLACED IN 
THE WAIT STATE 




NO 


WTO FB 


ISSUE ROLLIN 
MESSAGE 





EORIWTR 
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Chart DD. Rollout/Rollin I/O Routine 



C)LLOUT/ROLLI 
I/O 



D 



ENTERED FROM 
ROLLOUT OR ROLLIN 
CRITERIA ROUTINES 
WITH SPECIFIED IQE 
ADDRESS IN REGISTER 



0- 



INITIALIZE 
CHANNEL 
PROGRAMS 



ISSUE EXCP 



ISSUE WAIT 




NOTE-ECB IS POSTED 



RESET INTERFACE 

FOR CPINIT 

ROUTINE 



© 



CONSTRUCT 
■ OUTPUT MESSAGE 
AND ISSUE WTO 



CONSTRUCT 

OUTPUT MESSAGE 

AND ISSUE WTO 



I PR( 



ROLLIN 

PROCESSING 

ROUTINE 






ROLLOUT 

PROCESSING 

ROUTINE 



D 
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chart DE. SVC Purge Interface 



f SVC PURGE j 



PRGIOl 






BUILD AND 

ENQUEUE A NEW 

RIQE 




PRG 


02 








INITIALIZE RIQE 

AND THE PURGE 
PARAMETER LIST 






PRGIQ3 _y^ 










SVC PURGE 




PURGE I/O 

REQUESTS FOR 

TASK 
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Chart DF. SVC Restore Interface 



r~ — ^ 

I SVC RESTORE 1 



ATTEMPT TO GET 



LOC lEAROIOQ 



RESTORE TCBFX 

FLAG, DISPATCH 

FLAG AND 

REGISTERS 



DEQUEUE RIQE 

AND FREE THE 

STORAGE THAT IT 

OCCUPIED 



^A. .^ 

( ENTRY \ 



SVC RESTORE 

ADDRESS OF 

FIRST lOB IS IN 

REG 1 




DEQUEUE ROLLOUT 

IRB FROM TCB TO 

WHICH IT IS 

ENQUEUED 



ENQUEUE ROLLOUT 
IRB ON TCB 

WHOSE I/O IS TO 
BE RESTORED 



ENQUEUE ROLLOUT 

IRB ON ROLLOUT 

TCB 



SET TCBFX FLAG 

IN THIS TCB TO 

PREVENT 

ASYNCHRONOUS 

EXIT 



TASK SWITCH BN 

SET THE RESTORE 

TCB AS NEXT TO 

BE DISPATCHED 



f DIS 



3 



TASK SWITCH BN 

SET THE RESTORE 

TCB AS NEXT TO 

BE DISPATCHED 



( DIS 



D 
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Chart DG. Rollout/Rollin GETSTEP Routine 



( GETSTEP j 





INITIALIZE 

LIMIT 

PRIORITIES FOR 

READY "QUEUE 

SEARCH 




RESET LIMIT 

PRIORITIES FOR 

HIGH PRIORITY 

PASS 



NORMAL RETURN 
ADDRESS OF PQE 
THAT FILLS RE- 
QUEST IN REGISTER ■ 



SEARCH TCB 
READY QUEUE 



^ JSTCB FOUND ^- 
^S-^YES 




TEST STEP 

AGAINST ROLLOUT 

CRITERIA 



IEAQAPG2 




NORMAL RETURN 
WITH ADDRESS OF 
PQE TO BE ROLLED 
OUT IN REGISTER 



C-H3— ^ .^ 
RETURN TO ^ 
CALLER ] 

ERROR RETURN REGION 
THAT SATISFIES 
REQUEST CANNOT 
BE FOUND 



SET HIGH 

PRIORITY PASS 

SWITCH 



u. 
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Chart DH. Rollout/Rollin TESTSTEP Routine 




IEAQAPG4 



USER ROLLOUT 
CRITERIA 
APPENDAGE 




NORMAL RETURN 
ADDRESS OF PQE 
IS IN REGISTER 
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chart DI. Rollout/Rollin Reply Restore Routine 



RSTRQE 



^_A2 . 

f REPLY/RESTORE 1 



IS COMPARED 
WITH RQERO 




ACCESS TCB 

POINTER IN THIS 

RQE 



ACCESS JSTCB 

POINTER IN THIS 

TCB 



NOTE-INDICATE THAT 
REPLY MAY BE MOVED 
TO USER'S BUFFER 




ACCESS TEMP. 

BUFFER POINTER 

IN THIS ROE 

(OFFSET 12) 




REPLY PROC. RTN 



NOTE-SVC 3^ IS ISSUED. 
CONTROL IS PASSED VIA 
COMMAND PROCESSING RTN. 
AND MGCR RTN. 



u. 
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chart EA. TIME Routine 



lEAQRTOO 



( TIME \ 



DEVELOP TIME OF 

DAY IN 26 

MICROSECOND 

UNITS 



GET DATE FROM 

COMMUNICATIONS 

VECTOR TABLE 




CONVERT TIMER 

UNITS TO BINARY 

UNITS 




CONVERT BINARY 

UNITS TO 

DECIMAL UNITS 



( TYP 



D 



U76 



chart EB. 



STIMER Routine 



lEAQSTOO 



r' — ^ 

f STIMER j 



CONVERT INPUT 

TIME VALUE TO 

TIMER UNITS (IF 

NECESSARY) 




CONVERT LOCAL 

TIME TO AN 

ABSOLUTE 

INTERVAL 



REPLACE 

EXCESSIVE VALUE 

WITH 24 HOURS 




GET SPACE FOR , 

TOE AND REG 

SAVE AREA 



I lEAQTEOO 
TIMER SLIH 



FLAG 


TPB 




'RBFDYN' 


TO 


HK 


FREEI 


Al' 




COMPLETION 


OF 


TIMER EXIT RTN | 



STORE ADDR OF 

TOE IN TCBTME 

FIELD OF 

CURRENT TCB 



u 








INITIALIZE 

EVENT CONTROL 

BLOCK (ECB) 



IGC001 (S) 



SAVE FIRST WORD 

OF USER'S PSW 

IN TOE. FLAG 

TOE SS HAVING 

EXIT 
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Chart EC. 



TTIMER Routine 




r^' ^ 

f TYPE 1 EXIT j 



DETERMINE TIME 

REMAINING IN 

INTERVAL 




PLACE REMAINING 

INTERVAL INTO 
REG AND EXIT 
INFO INTO REG 1 



{ TYPl 



TYPE 1 EXIT 



) 
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Chart ED. Timer Second-Level Interruption Handler (Page 1 of 2) 







^A, ^ 

f TIMER SLIH j 




-A4- 



7^ 



INCREMENT DATE 

IN CVT AND 

PLACE 2a- ON 

VALUE INTO 
MIDNIGHT TQE 







REMOVE EXPIRED 

TIMER QUEUE 

ELEMENT (TQE) 

FROM QUEUE 






OBTAIN ACC WAIT 
TIME FROM 
SYSWSAVE 



SUBTRACT 6 

HOURS FROM ALL 

TQES ON QUEUE 




SWAP USER IN 




^ REAL/ 
TEST \, TASK 
INTERVAL TYPE 




ADD ACC WAIT 

TIME TO 

SMC AWAIT Sa 



PLACE 6-HOUR 
VALUE INTO 
6 -HOUR TQE 







0- 

TSNQUEUE_^,^ ■ 


IGC056 


PLftCE 10 MIN 




ENQ BI 




T{ 


)E 




QUt 


,Se "" 



REFORMAT 

EXPIRED TQE TO 

IRB FOR ASYNCH 

EXIT ROUTINE 



© 



STG2 EXT EFF BL 



0- 



POST ECB IN TQE 



TSENTIME 



SET COMPLETE 
FLAG IN TQE 



UPDATE TIMER 

FROM NEXT TQE 

ON QUEUE 



L 




OBTAIN ADDR OF 

INITIATOR'S TCB 

FROM TCT 






INIT IRB WITH 

lEATLEXT ADDR 

(TIME LIMIT 

EXPIRATION 

ROUTINE) 







INITIALIZE IQE 



STG2 EXT EFF BL 



L 
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Chart ED. 



Timer Second- Level Interruption Handler — Dequeue and Enqueue Subroutines 
(page 2 of 2) 



IEAQTD01 



lEAQTEOO 



lEAQTDOO 



r^' — ^ 

( BRANCH ENTRY I 



— A^ s. 

TIMER SLIH A 

ENQUEUE I 

SUBROUTINE J 



(BRANCH ENTRY) 




DEVELOP 
ABSOLUTE TIME 
REMAINING IN 
INTERVAL AND 
STORE IN TQE 




DEVELOP 'TOX' 

TIME VALUE 

RELATIVE TO 5 

MR CYCLE 




TNQTOX 



QUEUE TQE 



/" RET 



J 





I lEAOABOO 



SCHEDULE ABEND 



MOVE SAVED 

TIMER TO TQE 

VAL SLOT 







MARK TQE AS OFF 
QUEUE 
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Chart EE. TIME Routine with Systein/370 Time-of-Day Clock 



I EAQRTOO 




i 



SET REG TO 

ZERO; SET REG 1 

TO X'OF' 



r^' ^ 

►■(type 1 SVC exit! 




SUBTRACT TOD 

CLOCK VALUE 

FROM MNIGHT 

VALUE 




CONVERT BINARY 

TO HHMMSSTH 

FORMAT 



YES 


lEAOTIDT 


UPDATE DATE IN 
CVT (CVTDATE) 





(TYPE 



1 SVC EXIT 



5 



L 



© 



GET TIME OF DAY 

IN MICRO 

SECONDS 





SET TOD = 

TOD- 12 HRS. : 

SET HflLFDAY=12 




VAL CHECK RTN 



o 



ADD HALFDAY 

VALUE TO TIMER 

UNIT VALUE 



SET RETURN CODE 



►■(TYPE 



1 SVC EXIT 



[TJ 
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Chart EF. STIMER Routine with Systein/370 Time-of-Day Clock 



lEAQSTOO 
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Chart EG, TTIMER Routine with Systein/370 Time-of-Day Clock 



lEAQSTOO 




NO 


•^AS C 
f SPEC 


\NCEL ^\ 
[FIED ^ 


> 






CLEAR POINTER 

TO TOE 
(TCBTIME) IN 
CURRENT TCB 


















TIMER SLIH EH 






REMOVE TIMER 
ELEMENT 








FMBRANC 


;h 












FREEMAIN DA 








TQE AND SAVE 
AREA 




TEX 


[TX 










PLACE REMAINING 
INTERVAL^INTO 








INFO IN' 


REG 1 







/^ N 

fTYPE 1 SVC exit! 
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Chart EH. Timer Second-Level Interruption Handler with System/370 Time-of-Day Clock 



lEAQTIOO 





0- 







©^ 



UPDATE TIMER 

FROM NEXT TOE 

ON QUEUE; STORE 

NEW TOX IN SHPC 



L 





TDARKNESS 



CHANGE DATE IN 

CVT. ADD ONE 

DAY TO MIDNIGHT 

ELEMENT 




SUBTRACT 5 

HOURS FROM ALL 

TOE INTERVALS 

ZERO SHPC 



ET 




SET INTERVAL TO 
1 HOUR 



©^ 

NORSYNC i 



-F5- 



SET NEW 
INTERVAL IN TQE 



STG1 EXT EFF BK 



L 




RESET TIMER 

INTERVAL TO 1 

HOUR. RESET 

SYNCFLAG 



, INDICATE to: 
»-! NOT ON QUED 



S TIMER ENQ 



U 
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Chart FA. External Interruption and I/O Attention Handlers 




X A J s. 

/I/O ATTENTION^ 
( HANDLER j 




NO 


POST BH 


POST EXTERNAL 
ECB 





SET ATTENTION 

PENDING FLAG IN 

UCB 



G 



J 
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chart FB. Write-To-Operator 



NOTE C3-. WTO ISSUED BY 

COM TASK OR TASK 
HIGHER ON TCB QUEUE 







Aiultiple-line"\ 

( WTO LOftDl j 



WAIT 






WAIT BG 




WOE BUFFER 
REQUEST 



FREE RESOURCE 






r^ * 






MOVE MCS FLAGS 
TO WQE 












MOVE ROUTING 
CODES, DESC. 
CODES, MSGTYP 
FLAGS TO WQE 






1 





3 
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chart FC. Write-To-Operator with Reply 






OBTAIN WQE AREA 



ENQUEUE REQUEST 





r~ ^ 

*K ABENDO 1 



SETRQE 



CLEAR RQE AND 
MARK ROE 
AVAILABLE 




STORE TCB 
ADDRESS IN ROE. 
PUT RQE ON TOP 

OF CHAIN 




^3 . 

f WTO 1 
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chart FD. Communications Task Initialization Routine (Page 1 of 5) 



/COMMUNICATIONS 



0NS\ 
ION/ 



SAVE 

REGISTERS 

<INITIALIZE BASE> 

REGS 




PUT SLASH (/) 

BETWEEN CON AND 

ALT 




CONVERT CONSOLE 

ID TO EBCDIC 

PUT IN MSG 



LOCATE 

ALTERNATE 

CONSOLE UCB 

NAME 




PUT I (INPUT) 

NAME INTO 

MESSAGE 



LOCATE 

COMPOSITE 

CONSOLE UCB 

NAME 



PUT O (OUTPUT) 

NAME INTO 

MESSAGE 
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Cliart FD. Connnunications Task Initialization Routine (Page 2 of 5) 
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Chart FD. Coiranunications Task Initialization Routine (Page 3 of 5) 



^1 



CONVERT ROUTING 
CODES FOR 
PRINTING 




0- 





CONTXl _, 1 






.NO 




PUT HVPHEN PAST 

LAST ROUTING 

CODE 




UPDATE LOOP 
COUNTER 










NO 




SEPARATE DIGITS 

WITH COMMA 

INSTEAD OF 

HYPHEN 








CON 


0- 

rA2 ^, ■ 




YES 




PUT HYPHEN 






ROUT INC 


~. CODE 



REPLACE 
PREVIOUS 

ROUTING CODE 
WITH NEW 

ROUTING CODE 



PUT HYPHEN 

AFTER LAST 

ROUTING CODE 






SEPARATE 
ROUTING CODES 
WITH COMMA 



L 







REPLACE 

PREVIOUS 

ROUTING CODE 

WITH NEW 



L, 



E> 
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Chart FD. Coiranunications Task Initialization Routine (Page H of 5) 
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Chart FD. Coiranuni cat ions Task Initialization Routine (Page 5 of 5) 




YES 


GET MLWTO ID 




WTO FB 


ISSUE END OF 
MLWTO 








YES 


GRAPH CONS INIT 


LINK TO 
INITIALIZE 
GRAPH CONS 





U92 



chart FE. Graphic Console Initialization Routine 
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Chart FF. Wait — Communications Task without Multiple Console Support 
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chart FH. Console Switch — Commiinications Task without Multiple Console Suppoart 
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Chart FI. Router — Communications Task with Multiple Console Support 
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Chart FJ. 



Console Switch 
CPage 1 of 3) 



Load 1 — Communications Task with Multiple Console Support 
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Chart FJ. Console Switch Load 1 — Communications Task with Multiple console Support 
(Page 2 of 3) 
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Chaart FJ, 



Console Switch Load 1 — CommTinications Task with Multiple Console Support 
(Page 3 of 3) 
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Chart FK. Console Switch Loads 2 and 3 — Comitruni cations Task with Multiple Console 
Support (Page 1 of 2) 
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Chart FK- Console Switch Load 3 — Communications Task with Multiple Console Support 
(Page 2 of 2) 
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Chart FL. Console Switch Load 4 — Communications Task with Multiple Console Support 
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chart FM. Device Interface — 
(Page 1 of 3) 



Communications Task with Multiple Console Support 
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Chart FM, Device Interface — Cominunications Task with Multiple Console Support 
(Page 2 of 3) 
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Chart FM. Device Interface — Communications Task with Multiple Console Support 
(Page 3 of 3) 
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Chart FN. 



WTO/R Processor 
(Page 1 of 3) 



Conununi cations Task with Multiple Console Support 
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Chart FN. WTO/R Processor — Communications Task with Multiple Console Suppoirt 
(Page 2 of 3) 
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Chart FN. 



WTO/R Processor — 
(Page 3 of 3) 



Conimunications Task with Multiple console Support 
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Chart FO- Delete-Operat or- Message (DOM) Processor — Communications Task with Multiple 
Console Support 
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Chart FP. NIP Message Buffer Writer — communications Task with Multiple Console Support 
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Chart FQ. 1052 Processor 1 — Communications Task without Multiple Console Support 
(Page 1 of 2) 
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Chart FQ. 
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1052 Processor 1 — Coiranunications Task without Multiple Console Suppori: 
(Page 2 of 2) 
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chart FR. 1052 Processor 1 — Communications Task with Multiple console Support 
(Page 1 of 2) 
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chart FR, 



1052 Processor 1 — Communications Task with Multiple Console Support 
(Page 2 of 2) 
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chart FS. 1052 Processor 2 — Communications Task with Multiple Console Support 
(Page 1 of 2) 
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Chart FS. 1052 Processor 2 — 
(Page 2 of 2) 



Communications Task with Multiple Console Support 
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chart FT. 1052 Open/Close 
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Chart FD. 2540 Processor — Communications Task without Multiple Console Support 
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Chart FV. 2540 Processor — Coiranunications Task with Multiple Console Support 
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Chart FW. 2740 Processor — Communications Task with Multiple Console Support 
(Page 1 of 2) 
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Chart FW. 2740 Processor — Communications Task with Multiple Console Support 
(Page 2 of 2) 
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Chart GB. LOG, Write-to-Log 
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Chart GC. LOG, Write-'to-Log — Load 2 
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Chart GD. Multiple-Line Write-to-Operator — I^sad 1 
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Chart GE. Multiple-Line Write-to-Operator — Load 2 
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chart GF. Multiple-Line Write-to-Operator — Load 3 
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chart GG. Multiple-Line Write-to-Operator — Load 4 
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chart HA. DIDOCS Processor 0, Load 1 (Page 1 of 2) 
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Chart HA. DIDOCS Processor 0, Load 1 (Page 2 of 2) 
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Chart HB. DIDOCS Processor 0, Load 2 (Page 1 of 2) 
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Chart HB. DIDICS Processor 0, Load 2 (Page 2 of 2) 
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Chart HC. DIDOCS Processor 1, Load 1 (Page 1 of 2) 
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Chart HC. DIDOCS Processor 1, Load 1 (Page 2 of 2) 
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Chart HD. DIDOCS Processor 1, Load 2 
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Chart HF. DIDCX:S 2250 I/O-l Routine (Page 1 of 2) 




GET X, Y 

COORDINATES, 

SAVE LINE AND 

CHARACTER 

POSITION 



C— F5 *. 
LIGHT A 
PEN/CURSOR J 



538 



Chart HF. DIDOCS 2250 I/O-l Routine (Page 2 of 2) 
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Chart HG. DIDOCS 2250 1/0-2 Routine 
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Chart HH. DIDOCS 2260 I/O-l Routine 
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Chart HI. DIDOCS 2260 I/0-2 Routine 
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Chart HJ. DIDOCS Model 85 I/O Routine 
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chart HK. DIDOCS Asynchronous Error Routine (Page 1 of 3) 
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chart HK. DIDOCS Asynchronous Error Routine (Page 2 of 3) 
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Chart HK. DIDOCS Asynchronous Error Routine (Page 3 of 3) 
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chart HL. DIDOCS Message 1 Routine 
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Chart HM, DIDOCS Message 2 Routine (Page 1 of 2) 




SET TO PUT 

MESSAGES IN 

INSTRUCTION 

LINE 



SET UP TO PUT 

ALL HSGS IN 
WARNING LINE 




BLINST RTN 




BLANK 

INSTRUCTION 

LINE 







PUT MESSAGE IN 

INSTRUCTION 

LINE 



BLENTRTN RTN 



INDICATE WRITE 

INSTRUCTION 

LINE 





SET UP TO WRITE 

BOTH LINES OF 

ENTRY AREA 



PUT ENTER 

CANCEL MESSAGE 

IN INSTRUCTION 

LINE 



INDICATE ERROR 

MESSAGE IN 

INSTRUCTION 

LINE 



SET EXIT TO 

PROPER I/O 

ROUTINE 



IL. 

r~^' ^ 

*■{ I/O ROUTINE j 
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Chart HM. DIDOCS Message 2 Routine (Page 2 of 2) 



BLINST RTN 



BLANK 

INSTRUCTION 

LINE 



PUT ERROR 

MESSAGE IN 

INSTRUCTION 

LINE 




DT5 


^. 


NO ^ 


MOVE IN REST OF 
MESSAGE 





1 



BLENTRTN RTN 



1 



BLINST RTN 



BLANK 

INSTRUCTION 

LINE 



PUT COMMAND 

REJECT MESSAGE 

IN INSTRUCTION 

LINE 




I— ►[oT 



B 



PUT MESSAGE IN 

SECOND LINE OF 

ENTRY AREA 



1 



BLINST RTN 



BLANK 

INSTRUCTION 

LINE 



FIND WHERE TO 

INSERT CURSOR 

AND HOLD 

LOCATION 
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Chart HN. DIDOCS Message 3 Routine 



:6D07B 
^A, ^ 

f MESSAGE 3 J 



DETERMINE TYPE 
OF MESSAGE TO 
BE DISPLAYED 




PUT ERROR 

MESSAGE IN 

INSTRUCTION 

LINE 



PUT ERROR 

MESSAGE IN 

INSTRUCTION 

LINE 





YES ^ 


BLINST RTN 




PUT ERROR 

MESSAGE IN 

INSTRUCTION 

LINE 


BLANK 

INSTRUCTION 

LINE 







L 







i 



INDICATE WRITE 

INSTRUCTION 

LINE 




D6 1 

PUT ' ENTER 
CANCEL" MESSAGE 



VES 


BLINST RTN 




PUT ERROR 

MESSAGE IN 

INSTRUCTION 

LINE 




CONVERT PFK 

NUMBER FOR 

PRINT 


BLANK 

INSTRUCTION 

LINE 









INDICATE ERROR 

MESSAGE IN 

INSTRUCTION 

LINE 



L 



© 







L 







SET EXIT TO 

PROPER I/O 

ROUTINE 







=IEECVETP (2250) 
lEECVETR (22601 
lEECVETH (MOD 85) 
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chart HO. DIDOCS Display 1 Routine (Page 1 of 2) 



-^A, \ 

f DISPLAY 1 j 




Section 13: Charts 551 



chart HO. DIDOCS Display 1 Routine (Page 2 of 2) 



^txAlT 

^A3 ^ 

( DELETE 2 1 




r~^'~- — ^ 

( DISPLAY 2 \ 



(^ ^ 

( DELETE ^ 1 



r~ ^ 

►I MESSAGE 1 I 
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Chart HP. DIDOCS Display 2 Routine CPage 1 of 2) 



f DISPLAY 2 j 



SPLIT MESSAGE 

AT MAXIMUM 

LENGTH OF LINE 






3f CA 

■G 



*-( DISPLAY 1 



J 



GET LINE ONE 



SETIMER IGC047 

— D2 

STIMER 




^r~'' ^ 

►f MESSAGE 1 j 




ACCEPTED \^ YES 

REPLY 
CONTINUED , 



MARK 
CONTINUATION AS 
AUTO DELETABLE 




r~'' ^ 

►i I/O ROUTINE I 



GET LINE ONE 



/Troc 

I LO 



D 





MARK 
CONTINUATION AS 
AUTO DELETABLE 
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Chart HP. DIDOCS Display 2 Routine (Page 2 of 2) 








MARK 
CONTINUATION AS 
AUTO DELETABLE 



U 
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CHART HQ. DIDOCS Display 3 Routine (Page 1 of 2) 



IGC6207B 






( DISPLAY 3 J 






FROM DISPLAY 1 
CHART HO 




(^0^ 


IEECVFT2 Js^ INTFACE1__ | 


C WR 

^^FINI> 


^WTO^X^NO 


INITIALIZE FOR 

INTERFACE 1 

EXIT 


HED^X^ 




GET NEXT WORD 



L 



© 



ADJUST POINTERS 
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Chart HQ. DIDOCS Display 3 Routine (Page 2 of 2) 




MOVE IN MESSAGE 

AND MARK DOM 

AND SCT 



EXAMINE MESSAGE 

TYPE AND MARK 

ACCORDINGLY 




MARK SCT AND 

INCREMENT 

COUNTER 



SET WRITE 

MESSAGE WAITING 

FLAG 






SET ON WRITE 

UNVIEWABLE 
MESSAGE FLAG 



ADJUST POINTERS 



L 







_ ''YES /^~*\ 
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Chart HR. DIDOCS Roll Mode Routine 








INT 


-. 




DETERMINE ROLL 
COUNT 




ADJUST COUNT OF 
ACTION MESSAGES 


^r^ 








H 








DROLL 








DETERMINE ROLL 
COUNT 




0- 






UP 










SET UP 

ADDRESSES FOR 

ROLL 




C TIMER N 
INTERPRETER I 



L 











1 



FIND CONTIGUOUS 
GROUP OF 
DELETABLE 
MESSAGES 



SET UP 

ADDRESSES FOR 

ROLL 



PERFORM ROLL 
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Chart HS. DIDOCS Command Routine 
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Chart HT. DIDOCS Options Routine (Page 1 of 2) 



SET UP OPERANDS 

AND VALUES FOR 

DISPLAY 




SET MESSAGE 1 
RTN. BIT 




POINT CURSOR TO 
VALUE OF DEL 







E> 
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chart HT. DIDOCS Options Routine (Page 2 of 2) 



INDICATE 

INVALID OPERAND 

ERROR MESSAGE 



INDICATE 

DEL=Y , CON=N 

WARNING MESSAGE 




^ P4 ^ 

f TIMER A 

(INTERPRETER RTNJ 



r^" ^ 

f MESSAGE 1 1 



(^ ^ 

( I/O ROUTINE j 



EP=IEECVETP (2250) 
lEECVETR 22601 
lEECVETH (MOD 85) 
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Chart lA. DIDOCS Delete 1 Routine (Page 1 of 2) 



© 



1 



BCONVERT RTN 



CONVERT HIGH 

NUMBER TO 

BINARY 



C-A " 


BCONVERT RTN 


CONVERT LOW 

NUMBER TO 

BINARY 
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Chart lA. DIDOCS Delete 1 Routine (Page 2 of 2) 



GET SCT MASK 

FOR PROPER 

DELETE 



NUMBER RTN 



MARK EACH 

MESSAGE WITH 

PROPER 

INDICATOR 




INDICATE NO 
DELETABLE 
MESSAGES 



Ui 



B 



-E2- 



INDICATE 

VERIFICATION 

MESSAGE NEEDED 

IN INSTRUCTION 

LINE 



CURSCOMP RTN 



( ME; 



MESSAGE 1 



) 



562 



Chart IB. DIDOCS Delete 2 Routine 



r' ^ 

f DELETE 2 \ 






MARK DOMHED 

MESSAGES AS 

AUTO DELETABLE 



VES 




INDICATE 
■ MARKING 
REQUIRED AT 
NEXT ENTRY 




BR14 






YES 


'\ 




INCI 


^ ^DELETE ^v, 





4 

( MCS ROUTER 1 







1 



PROCESSOR 1 A 
LOAD 1 j 



SET COUNTER TO 

NUMBER OF 

MESSAGE LINES 

ON SCREEN 



G 



3 



SET POINTER TO 

FIRST MESSAGE 

IN SCT 





MARK ACTION MSG 

WITH REPLIES 
AUTO DELETABLE 



INDICATE 

PERFORM AUTO 

DELETION 



►( DELETE 4 1 



Section 13: Charts 563 



chart IC, DIDOCS Delete 3 Routine (Page 1 of 2) 




ALTER POINTERS 
TO INCLUDE 
FIRST LINE 



FIND FIRST 

MESSAGE ENTRY 

IN SCT 



INDICATE DELETE 

REQUESTED AND 

MESSAGE 

DELETABLE 



SET UP TO LOOP 

THROUGH 

MESSAGES 





© r 
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Chart IC. DIDOCS Delete 3 Routine (Page 2 of 2) 
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Chart ID. DIDOCS Delete 4 Routine 



r~"' — ^ 

( DELETE 4 j 
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Chart IE. DIDOCS Light Pen/Cursor Routine 




YES 


■INDICATE BAD 

LIGHT PEN 

DETECT 
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Chart IF. DIDOCS Timer Interpreter (Page 1 of 2) 



r^" ^ 

r DISPLAY 1 1 




L 
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Chart IF. DIDOCS Timer Interpreter (Page 2 of 2) 





( OPEN/CLOSE j 



( I/O RTN . j 



( MESSAGE 1 j 



( MESSAGE 2 J 
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Chart IG. DIDOCS PFK 1 Routine (Page 1 of 2) 



r~ ^ 

f PFK 1 j 



SET SWITCH 

REGISTER TO 

LABEL 'VALID' 








L 







CONVERT 

LOCATION TO KEY 

NUMBER 



u 



SET SWITCH 

REGISTER TO 

LABEL 'CANMAS' 



1 F3 

SET FLAG 
(DCMUTILB) 
MASTER KEY 
IN USE 


IF 
IS 



© 



1 



SET UP ERROR 

MESSAGE AND SET 

EXIT FOR 

MESSAGE 1 



r 




^ 1 

/^PRO( 
(l/O I 
V_M1 



PROCESSOR 
'1 ROUTINE 
MESSAGE 



g). 




L 



© 







1 




L 







SET UP NEXT KEY 
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Chart IG. DIDOCS PFK 1 Routine (Page 2 of 2) 



MOVE FIRST OR 

NEXT COMMAND TO 

ENTRY AREA 




TURN ON ISSUE 

FLAG AND SET 

EXIT FOR 

PROCESSOR 1 



\^YES 
WRIT 




INDICATE 
VERIFY, WRITE 

ENTRY, AND 
INSERT CURSOR 


10 





SET EXIT FOR 

DEVICE 
DEPENDENT I/O 

ROUTINE 
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Chart IH. DIDOCS PFK 2 Routine 



r~ ^ 

\ PFK 2 1 




CHECK MASTER 

KEY FOR 

VALIDITY 



CHECK OPERAND 

AND SET FLAG AS 

REQUIRED 




KEY IN LIST 
MUST NOT BE A 
LIST OF KEYS 



ENDEF 
YES 



\ ^^^ \S CON 

< operan: 
^w expecte; 




L 
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chart II. DIDOCS Cleanup (Page 1 of 2) 



r' ^ 

( CLEANUP j 



VFTG 

STTYPE ^.^N. 

-•^EANUP FO^\f 
^ CLOSE ^ 

^S-^YES 



INDICATE FREE 

IN-LINE 

MESSAGES 





ISSUE PM A 




r 




REINITIALIZE 

POINTER TO END 

OF VIEWABLE 

MESSAGE AREA 



INDICATE NO 

DISPLAYS ON 

SCREEN 



Section 13: Charts 573 



chart II. DIDOCS Cleanup (Page 2 of 2) 




CLOSEEXT f 



^1 . 

r RETURN j 
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Chart IJ. Status Display Interface 1 Routine 





LOCATE NEXT 
MINOR ON WQE 







1 



SET FLAGS 
INDICATING 
SCREEN FULL 




IF REQUIRED. 
SET HftRDCOPY 



IF REQUIRED, 

INCLUDE 
HARDCOPY TEXT 



MOVE TEXT FROM 

WQE TO DCM, 

DECREMENT USE 

COUNT 




SET DESCRIPTOR 

CODE FLAGS IN 

SCT 




© 



1 



INDICATE LINE 

NUMBER TO BEGIN 

WRITE 



IK 

C— B3 N. 
PROCESSOR 1 A 
LOAD 1 J 




MORE LINES 



° © 



D3^\v PEXIT 

-►^ ROLL MODE ^ ►( I/O ROUTINE j-* 

^SX'YES 



G 



EP=IEECVETP (2250) 
lEECVETR 2260) 
lEECVETH (MOD 85 




3 



r~ ^ 

( MESSAGE 1 1 



EP=IEECVFT2 
CHART HQ 
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chart IK- Status Display Interface 2 Routine (Page 1 of 2) 




INDICATE 

BLANKING MUST 

BE CHECKED 



SAVE 

INFORMATION 

ABOUT THE TOP 

DISPLAY 



r 
'0 



CLEAR 

CORRESPONDING 

PORTION OF S5CT 





INITIALIZE SACB 

FOR THIS 

DISPLAY 




INITIALIZE SACB 

AND SSCT FOR 
DYNAMIC DISPLAY 



C'ATU S DISPLAyN 
INTERFACE 6 \ 




C— H5 ^^ 
PROCESSOR 1 \ 
LOAD 1 \ 



/st; 





D 



1 



u 
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chart IK. Status Display Interface 2 Routine (Page 2 of 2) 




FREE ANY MINORS 
LEFT ON QUEUE 



FREE OLD 

DISPLAY'S MAJOR 

WQE 



©- 



CLEAR SACB 



L 



I FINDNEXT 1 




• 



GET MINOR 

POINTER SAVED 

IN SACB 



pointerSw 






GET POINTER TO 

FIRST MINOR ON 

QUEUE 






3 
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Chart IL. Status Display Interface 3 Routine (Page 1 of 2) 



r] 



D 



FIND SACB TO 
MATCH AREA ID 
IN PARAM LIST 



BLANK 

INSTRUCTION 

LINE 




YES 


TURN OFF FRAME 

FULL BIT IN 

SACB 




MASKRTN 


SET BIT IN WOE 
OFF 







HOVE P MA 

COMMAND TO 

DCMINPUT LIST 




U 



E> 



HOVE MN A 

COHMAND AND 

AREA ID TO 

DCHINPUT LIST 



L 



B 



TURN ON 

OUT-OF-LINE 

DISPLAY PENDING 

FLAG 



L 
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chart IL- Status Display Interface 3 Routine (Page 2 of 2) 



SET UP MCS 

FLAGS, LIST, 

AND ISSUE SVC 

34 




SET UP BYTE 

COUNT, LINE 

NUMBER FOR I/O 



MOVE TITLE FROM 

SCREEN IMAGE 

BUFFER LINE 




MOVE IN FIRST 

SET OF 
ASTERISKS AND 
FRAME NUMBER 




MOVE HOLD MODE 

OPTIONS F AND U 

INTO LINE 



MOVE STATIC 

DISPLAY OPTIONS 

F AND E 



MOVE UPDATE 

OPTIONS PM AND 

H INTO LINE 



CONVERT CONSOLE 

ID AND MOVE IT 

AND AREA ID 

INTO LINE 



I I/O 







EP=IEECVETP (2250) 
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Chart IM< Status Display Interface U Routine 




TURK REWRITE 

CONTROL LINE 

FLAG OFF 



BUILD CONTROL 

LINE IN FIRST 

LINE OF WRITE 

AREA 




TURN OFF 

FRAMING IN 

PROGRESS FLAG, 

FREE MAJOR WQE 



L 



© 



MOVE BLANKS 
INTO FIRST LINE 
OF WRITE AREA 



MOVE BLANKS 
INTO 2ND LINE 
OF WRITE AREA 



MOVE BLANKS 
INTO THIRD LINE 
OF WRITE AREA 



L 



© 



© 



BUILD CONTROL 

LINE IN FIRST 

LINE OF WRITE 

AREA 



MOVE TEXT INTO 

FIRST LINE OF 

WRITE AREA 



1 



INDICATE 

REWRITE CONTROL 

LINE 



INDICATE 

CONTROL LINE IN 

SSCT 



©- 

LINE2 

MOVELINE 



MOVE TEXT INTO 

SECOND LINE OF 

WRITE AREA 



UPDATE CONTROL 

FIELDS FOR NEXT 

LINE 



MOVE TEXT INTO 

THIRD LINE OF 

WRITE AREA 






INDICATE BLANK 

REST OF AREA 

NEEDED 




EP=IEECVETP (2250) 
lEECVETR (2260) 
lEECVETH (MOD 85) 
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Chart IN. Status Display Interface 5 Routine (Page 1 of 3) 




BLANKRTN | 



TURN DCMCHIN5 

OFF, GET LINE 

COUNT TO BLANK 



SAVE LINE COUNT 

MINUS FOR NEXT 

ROUND 




LOAD FIRST SACB 

POINTER AND 

INITIALIZE 

INSTRUCTION 

LINE POINTER 



BLANK ENTRY 

AREA AND 

INSTRUCTION 

LINE 




INDICATE TO I/O 

TO WRITE 

DISPLAY 



E.A11 

G 



I/O ROUTINE 



) 



EP=IEECVETP (2250) 
lEECVETR (22601 
lEECVETH (MOD 85) 



SAVE POINTER TO 

TOP LINE OF 

DISPLAY 



L 
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Chart IN. Status Display Interface 5 Routine (Page 2 of 3) 




582 



Chart IN. Status Display Interface 5 Routine (Page 3 of 3) 




TURN ON FLAGS 

TO BLANK AND 

WRITE WARNING 

LINE 







INDICATE WRITE 

PARTIAL MESSAGE 

AREA 
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Chart lO. Status Display Interface 6 Routine (Page 1 of 2) 




584 



Chart 10- Status Display Interface 6 Routine (Page 2 of 2> 




INDICATE FRAME 

FULL IN MAJOR 

WQE 



TURN OFF 

FRAMING- IN- 

PROGRESS FLAG 



FIND FIRST LINE 

TO BE WRITTEN 

NEXT FRAME 




INDICATE WRITE 

PARTIAL MESSAGE 

AREA 



( I/O 







EP=IEECVETP (2250) 
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Chart IP. Status Display Interface 7 Routine 




EP=IEECVETP (2250) 
leECVETR 2260i 
lEECVETH (MOD 85) 



YES 
< 


/ IS A ^^ 
y< MESSAGE ^S. 

Q UNDERNEATH ^ 


\ 


^0 










BUMP BLANK LINE 
COUNTER 


BLNI 


► 

CONLY 






SET BLANK 

INDICATOR ON IN 

SSCT 
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Chart JA. Checkpoint Housekeeping 1 Routine 




( EXIT j 



CHKPT CANCEL 

WORK AREA 

SP=250 




SET MESSAGE 

CODE AND RETURN 

CODE 



CALC. WK. AREA 

SIZE FOR RESTRT 

PROG, CALC NO. 

OF DEBS AND 

TIOT SIZE 



INITIALIZE WORK 

AREA WITH INFO 

TO BE USED BY 

SUBSEQUENT 

LORDS 




- IGCOO^(S) 



INVALID PORTION 
OF CHKPT WORK 
AREA (SP=250) 



L0 



L 



Section 13: Charts 587 



Chart JB. Checkpoint Housekeeping 2 Routine 



f CHECKPOINT A 
f H0USEKEEPING2 1 








GET MAX BLKSIZE 
ALLOWED ON DEV . 
FOR CHKPT D.S. 






SET MESSAGE 

CODE AND RETURN 

CODE 



(CHECI 



CHECKPOINT EXIT 



5 





/' — K 

(house: 



D 



^0 




JOB 

INVOKING 

ROLLOUT 





INDICATE 

POSSIBLE ERROR 

IN RETURN CODE 

AND MESSAGE 

CODE 
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Chart JC, Checkpoint Housekeeping 3 Routine 



f CHECKPOINT ^ 
I HOUSEKEEPINGS j 



FROM HOUSEKEEPING 1 CHART JA 
HOUSEKEEPING 2 CHART JB 
PRESERVE 1 CHART JE 



Bl- 



CONSTRUCT ECB, 

lOB, CHANNEL 

PROGRAM TO BE 

USED TO WRITE 

RODS 6 STOR 



GET TTR OF JCT 




CONSTRUCT CHR 

(CHKPT HEADER 

RCD) IN BUFFER 

OF CHKPT WORK 

AREA 



READ JCT INTO 

BUFFER OF CHART 

WORK AREA 




MOVE SYSTEM- 
GENERATED 
CHECKID TO 
USER -PROVIDED 
FIELD 



PAD REMAINING 

BUFFER WITH 

ONES 




r~ ^ 

( CHECK I/O \ 



SET MESSAGE 

CODE AND RETURN 

CODE 



INCREMENT 

JCTNRCKP FIELD 

(NO. OF CHKPTS 

TAKEN) IN JCT 

BY ONE 



L0 
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Chart JD. Checkpoint Check I/O Routine 
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Chart JE. Checkpoint Preserve 1 and 2 Routines 







r~'' ^ 

I PRESERVE 1 1 



r' ^ 

( PRESERVE 2 j- 




^ ANOTHER TIOT 
NO 



/~ 7 

/ READ JFCB / 
/ (TTR IN TIOT / 
/ ENTRY ) / 






r^' 7 

/ READ JFCB / 
/(TTR FROM SIOT)/-*- 







NOTE TTR OF THE 
CHR AND SAVE IN 
CHKPT SAVE AREA 



F2 

CKRETCOD 

X'0008' 

CKMSGCOD 

X'OOIB' 



©- 

{ RESl 



RESUME I/O 



3 



X H 

f CHEi 
( HOUS 



d 



PRESERVE 2 



/ READ IN GDG / 

-W BIAS COUNT / 

/ TABLE / 



BUFFER HANDLER 



WRITE BUFFER IF 

FULL. MOVE REC 

TO BUFFER 




WRITE BUFFER 



PLACE VOL, SEQ. 

NO. FROM DEB 

INTO JFCB 



' ' PREOBH 

H3-2 

BUFFER HANDLER 



WRITE BUFFER IF 
FULL, HOVE REC, 
UCBTYP TO BUFF. 



EBVLSQ) , PLACE 
INTO JFCBVLSQ 




CHECKHAIN 1 



BUFFER HANDLER 



WRITE BUFFER IF 

FULL, HOVE 
RECORD TO BFR. 




-»-C ANOTHER JFCBX 






•0^ 
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Chart JF. Checkpoint Checkmain 1 and 2 Routines (Page 1 of 2) 



© 



r' ^ r~ ^ 

( CHECKMAIN 1 \ f CHECKMAIN 2 \ 



WRITE RTN 



CIR OF PROS. 
PROG STOR ABOVE 
CHKPT WK AREA 



-B2- 



i 



GET PROB, PROG 

TCB CHECKMAIN 

ADDR 



INIT, SUR 

LENGTH=200 

BYTES, GET P/P 

TCB ADDR, GET 

DUMMY PQE ADDR. 



WRITE RTN 



WRITE CIR OF 
PROB PROG STOR 
BELOW CHKPT WK 



WRITE RTN 



WRITE CIR OF 

HIERARCHY ONE 

IF PRESENT 




GET PQE ADDR 




1 



© ©- 



^ ANY PBQES ^ 
^SX'YES 



■0 



NO 


WRITE SUR 


WRITE SUR OF 

PQE £ PBQE IN 

CHKPT ENTRY 





WRITE SUR 



WRITE 

SUPERVISOR 

RECORD OF PQE 



GET NEXT CDE 




^ MORE CDES y^ 1 



WRITE SUR 



WRITE SUR OF 

CDE IN CHKPT 

ENTRY 



Ul 



^ 



GET CKPT SVRB 

ADDR- GET NEXT 

RB ADDR. 



IS IT A PRB 




GET INITIATOR'S 

TCB ADDR, GET 

L-SHflPED PROG'S 

TCB ADDR 



©- 





©F 




YES 


GET TACT ENTRY, 

OFFSET OF NSI 

IN TRANS. 

AREA.SVRB 

LENGTH 














YES 


GET LENGTH OF 
SVRB 




















NO 


WRITE SUR 










SVRB I 
EN 


J CHKPT 
rRY 





Fk>- 



■F5- 



GET NEXT LLE 
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Chart JF. Checkpoint Checkmaln 2 Routine (Page 2 of 2) 




NO 




GET NEXT CDE 







^m 


WRITE SUR 


WRITE SUR OF 

CDE IN CHKPT 

ENTRY 





L fc-foT 



B 
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Chart JG. Checkpoint Checkmain 3 Routine 



(^ ^ 

( CHECKMAIN 3 \ 



FROM 

CHECKMAIN2 
CHART JF 




GET NEXT RB 





WRITE SUR 




© 



n 



WRITE SUR 



WRITE PIE INTO 

SUR IN CHKPT 

ENTRY 



WRITE SUR 



WRITE SAVE AREA 

INTO CHKPT 

ENTRY 



GET ADDR OF P/P 

SAVE AREA IN 

TOE OFF 

INITIATOR'S TCB 



WRITE SUR 



WRITE SAVE AREA 
INTO SUR IN 
CHKPT ENTRY 







WRITE SUR 


WRITE G.P. REGS 
INTO SUR 



SAVE OFFSET TO 

DEB BASIC 

SECTION 



WRITE SUR 

WRITE SUR OF 

DEB IN CHKPT 

ENTRY 



L 




CI " 




D' " 


GET NEXT DEB 




WRITE SUR 


WRITE SUR OF 

IRB IN CHKPT 

ENTRY 









-^ MORE DEBS ^ 



WRITE SUR 



WRITE SUR OF 

F/P/ REGS IN 

CHKPT ENTRY 







GET CHKPT DCB 
ADDR 



WRITE SUR 



WRITE SUR OF 

DCB IN CHKPT 

ENTRY 



GET TIOT ADDR 



WRITE SUR 

WRITE SUR OF 

TIOT IN CHKPT 

ENTRY 



I re; 



RESUME I/O 



D 
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Chart JH. Checkpoint Resume I/O and Exit Routines 




■0 



\ 


/'YES 




\ 


^YES 




t). 




■ 






J, 




CK RETCOD = 
X'DOOO' 




MOVE CHECKID TO 
JCT 















0- 



FREE CHKPT WORK 

AREA- LOAD 

RETURN CODE 




^ ^ 

( EXIT j 
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Chart JI. Checkpoint Message Routine 



CHECKPOINT A 
MESSAGE j 



GET MAIN 

STORAGE FOR HSG 

AREA 




MOVE 'NOT 

TAKEN' MESSAGE 

TO MSG. AREA 



MOVE JOBNAME, 

DDNAME, VOLUME 

SERIAL NO. , 

UNIT NAME i 

CHECKID TO MSG. 





CONVERT AND 

MOVE ERROR CODE 

TO MESSAGE 



MOVE 'ERROR' TO 

MESSAGE, 

MESSAGE ID = 

'IH3002I' 



MOVE 'ENDS' T 
MESSAGE . 
MESSAGE ID 
IHSOOSI 



0-- 



MOVE 'INVLD' 
MESSAGE . 
MESSAGE ID ^ 
IHSOOII 



CONVERT AND 

MOVE ERROR CODE 

TO MESSAGE 




G 



3 
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chart JJ. Restart Housekeeping 1 and 2 Routines 



f RESTART ■ A 

(HOUSEKEEPING 1 j 



/' ^3 \ 

f RESTART ^ 

fHOUSEKEEPING 2 j 




' ■ IGC004(S) 




-Ba- 



MOVE D.A. lOB, 

ICBS, CHAN PROG 

TO REST. WK 

AREA FOR 

READING STORAGE 



MOVE TAPE lOB, 


ICB'S e CHN 


PRGH TO REST. 


WRK AREA FOR 


READING STOR 



UPDATE lOB IN 
DCB-UPDATE TCB 
ADDR, NEXT lOB 

ADDR, CHN PRG 
ADDR 



WORK AREA WITH 

INFO IN DSDR 

PARM LIST 



UPDATE lOB IN 
DCB, ECB ADDR, 
NEXT lOB ADDR ( 

CHAN PRG ADDR 



-El- 



CALC REST. WK 

AREA OFFSETS 

FOR REPMAIN AND 

REPDCB'S l-nC 

AREA 



-E3- 



COMPUTE LENGTH 
AND OFFSET OT 
REPDCB'S WRK 

AREA IN RESTART 
WRK AREA 



-Fl- 



CONSTR, REST, 

DCB IN REST. 

WORK AREA TO BE 

USED TO READ IN 

P/P STOR. 





POSITION CHKPT 

ENTRY TO FIRST 

CIR 



POSIT CHKPT 

DATA SET TO 

CORR CHK ENTRY 



COMPUTE ADDR OF 

FIRST BYTE 

ABOVE RESTART 

WORK AREA 




r~ ^ 

( REPMAIN 1 1 



POSIT CHKPT 

DATA SET TO 

FIRST CIR 




j^ K^ ,. 

/ RESTART ^ 

•■(HOUSEKEEPING 2 j 

EP=IGC0205B 
CHART JJ/A3 



Section 13: Charts 597 



Chart JK. Restart Repmain 1 Routine 



f REPrMIN 1 1 



FROM RESTART 
H0USEKEEPING2 
CHART JJ 




SAVE DEB VOL. 

SEQ. NO. CHKPT 

DATA SET FOR 

EOV TEST 



SAVE 


DEB 


ADDR 


IN 


:hkp' 


WK 


AREA 


FOR 
TEST 


EOV 



READ IN STORAGE 

ABOVE CHKPT WK 

AREA 



READ IN STORAGE 

BELOW CHKPT WK 

AREA 



READ IN 

HIERARCHY 1 IF 

PRESENT 




CHECK LAST READ 

IF ERROR, TO 

EXIT RTN 



TEST FOR EOV IF 

EOV, TO RESTRT 

EXIT RTN 



L 



© 




PUT NEW PQE 
ADDR INTO FBQE 
PTRS OF NEW PQE 



j< ^v YES 
^ MORE PQES ^- 1 




598 



Chart JL. Restart Repmain 2 Routine 



JUOUDH 

r~" ^ 

( REPMAIN 2 1 




MOVE SVRB TO 
SQS 



MOVE PRB TO SQS 



-E3- 




MOVE PRTCT KEY 
FROM TCB TO RB. 
PUT RB ON RB CH 
OFF WK AREA GET 
INPUT BLK 



-E4- 



GET NEW ADDR OF 

NSI IN NEW 

TRANS AREA. 

STORE INTO SVRB 
PSW 




PUT CDE ON CDE 

CHAIN OFF WK 

AREA. GET NEXT 

INPUT BLK 



L 







Section 13: Charts 599 



Chart JM. Restart Repmain 3 and 4 Routines 



r~ ^ 

I REPMAIN 3 J 



FROM 

REPMAIN2 
CHART JL 



GET INPUT BLOCK 

MOVE ADDR OF 

P/P SAVE AREA 

INTO TCB 



GET INPUT 
BLOCK-MOVE ADDR 

P/P SAVE AREA 
INTO INIT'S TQE 



GET INPUT BLOCK 

MOVE CHKPT DCB 

ADDR TO WORK 

AREA 



GET INPUT 

BLOCK. RESTORE 

USER'S SYNAD 

ADDR 



GET INPUT 

BLOCK. MOVE 

GPR'S INTO 

RESTARTS SVRB 







1. 



SAVE OFFSET TO 

DEB BASIC 

SECTION, MOVE 

DEB TO S.P. 254 



f REPMAIN a j 




-B3- 



FROH 
REPMAIN3 
CHART JM 



SWAB TCB CHAIN 

PTRS WITH WK 

AREA PTRS. GET 

1ST CDE OFF TCB 

JPQ 



©- 




UPDATE DEB 

PROT. KEY 6 

APPENDAGE TABLE 

PTR, PUT DEB ON 

WK AREA CHAIN 




0- 



PUT TCB ADDR 

INTO DEB, GET 

INPUT BLOCK 




MOVE IRB TO 

S.P. 253 PUT 

IRB ADDR INTO 

DEB 



GET NEXT RB 







GET 1ST RB OFF 
TCB 




© 



1 



GET NEXT CDE 



~C MORE CDES ^ 
^^^ES 



U 




GET 1ST CDE IN 
JPQ OR LPQ 




RESTORE FP 
REGS. GET INPUT 
BLOCK MOVE TIOT ■ 
TO WORK AREA 



f A 

»•( REPMAIN a 1 

EP=IGC0805B 
CHART JM/A3 
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Chart JN. Restart Reprnain 5 Routine (Page 1 of 2) 



r"-' ^ 

f REPHAIN 5 1 




RESTORE P/P 
SPQE ADDR 




GET ADDR OF 2ND 

SPQE CHAIN TO 

BE FREED 


I 







GET ADDR OF 3RD 

SPQE CHAIN TO 

BE FREED 






Section 13; Charts 601 



Chaart JN. Restart Repmain 5 Routine (Page 2 of 2) 



GET ADDR OF 

FIRST LLE IN 

WORK AREA 





Q ANY LLES ^ 


\ 


/YES 




.. 


' LOOP 




FREE LLES 


»■ 






GET ADDR OF 

FIRST CDE IN 

WORK AREA 





NOTE 1 : FIRST OLD FREE 

AREA EXT. TO START 
OF OLD STORAGE 



BUILD NEW FIRST 

FBQE-CHAIN NEW 

FBQE TO OLD 

FBQE CHAIN 



ADD LENGTH OF 

NEW AREA TO OLD 

FIRST FBQE 



FREE CDE-FREE 

XL-GET ADDR OF 

NEXT CDE 




MORE CDES 




SET UP TO COMP 
CURRENT REGION 

BOUNDRS WITH 
BOUNDRS AT 

CHECKPT TIME 



L 



© 



FREE RESTART' S 




GET LENGTH OF 

NEW AREA-BUILD 

NEW LAST FBQE 




NOTE 2 : LAST OLD FREE 

AREA EXT. TO START 
OF OLD STORAGE 



CHAIN NEW FBQE 

TO OLD FBQE 

CHAIN 



ADD LENGTH OF 

OLD LAST AREA 

TO NEW 

FBQE-CHAIN NEW 



BUILD DUMMY 

FBQE AT START 

OF REGION 

DESCRIBING REG. 



K2 

TRANSFER TCB 

MSS CHAINS TO 

WK AREA- ZERO 

TCB MSS PTRS 

3 TCBS 




IN 



SET UP TO 

COMPARE HIER. 1 

CURRENT BNDRIES 

WITH HIER. 1 

CHKPT BNDRS. 



U 







602 



Chaart JO, Restart JFCB Processors 1, lA, and 2 



iJFCB PROCESSOR 



C 



) 



COMPUTE NO. 
DATA SETS, PUT 
DEBS INTO TABLE 



SEARCH NEW TIOT 

FOR CORRECT 

DDNAME 




INIT WRK AREA 

FOR EACH DATA 

SET- BUILD DCB, 

DEE, lOB AND 

CHAN. PROG. 



< 



'CB PROCESSOR 



) 




'JFCB PROCESSOR 



-c 



VES 


WAIT/PROCESS 


IF ERR, TO EXIT 

RTN -COMPLETE 

TABLE ENTRY 





WAIT/ PROCESS 



IF ERR, TO EXIT 

RTN -COMPLETE 

TABLE ENTRY 




COMPUTE NO XTNS 
TO READ, GET 
JFCB EXT. TTR 



©- 



I — 7 

i\ / EXCP/WAIT / 

I / READ JFCB / 

y / EXTENSION / 

'R0C1 ' ■ / 



ERROR C0DE^2iJ 



^n ^ 

I RESTART EXIT j 




MOVE CORRECT 

VOLID TO TABLE 

ENTRY 




/rem DATA set'N 

■I PROCESSOR j 



►■( MOUNT/VERIFY j 

EP=IGC0K05B 
CHART JQ 

EP=IGC0M05b 
CHART JR 



Section 13: Charts 603 



Chart JP. Restart Duminy Data Set Processor 



/Dur 



frN 




*■{ RESTART EXIT \ 




-*-(MOUNT/VERIFV 2 j 



GET STORAGE 

FOR, AND FORMAT 

DUMMY DEB 




ADD NEW DEB TO 
DEB CHAIN 




LOAD IGG019AV 

AND SET 

POINTERS TO IT 

IN DEB 







L 







604 



Chart JQ. Restart Mount Verify 1 Routine (Non-Direct Access) 







r~" ^ 

IMOUNT/VERIFY 1 1 



FROM JFCB 
PROCESSOR 2 
CHART JO 



1 



/^SYSIN/SYSOUT \ 
f NON-DASD \ 



■ >EP=IGC0L05B 




•-mOUNT/VERIFY 2 j 




GET NEXT UCB 

FROM LIST IN 

NEW TIOT 



r" — 7 

/ EXCP/WAIT / 
/ READ JFCB / 



GET NEXT ENTRY 
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Chart JR. Restart Mount Verify 2 Routine (Direct Access) 




606 



Chart JS. Restart SYSIN/SYSOUT Data Set Processors 1 and 2 (Non-Direct Access) 




ASYSIN/SVSOUT ^ 
I DATA SET 1 

V PROCESSOR 2 J 





n 









FROM SYSIN/SYSOUT 
D.S. PROCESSOR 1 
CHART JS/D3 



LAST ENTRY 



ASYSIN/SYSOUT ^ 

•-( DATA SET I 

\^ PROCESSOR 2 J 




CONVERT CURRENT 

AND NEXT lOB 

SEEK ID'S TO 

TTR 



READ IN JFCB 



/ 7 

/ READ IN DSCB / 



CALCULATE NUM. 

OF TRKS IN EACH 

EXT ENT 




PLACE LOWER 

LIMIT OF 1ST XT 

IN FULL DISK AD 

FIELD OF DCB 



CONVERT CURRENT 

AND NEXT- SEEK 

ID BACK TO 

MBBCCHHR . 



PLACE TRACK 

CAPACITY FOR 

DEV IN DCB 




MOVE INFO FROM 

OLD DEB TO NEVJ 

DEB 




REMOVE OLD DEB 

FROM DEB CHAIN, 

ADD NEW DEB 



Section 13: Charts 607 



Chart JT. Restart Data Set Processor 1 (Non-Direct Access) 



DATA SET ^ 
PROCESSOR 1 j 



FROM SYS IN 
SYSOUT DATA 
SET PROCESSOR 
CHART JS 



COUNT TABLE 
ELEMENTS WHICH 
REPRESENT TAPES 



COMPUTE WORK 

SPACE NEEDED - 

128 BYTES PER 

TAPE 




SET POINTER IN 

EACH TABLE 

ELEMENT TO A 

WORK AREA 



f DATA SET A 
( PROCESSOR lA 1 
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Chart JU. Restairt Data Set Processor lA — Non- Direct Access (Page 1 of 2) 



/ DATA SET A 
( PROCESSOR lA j 



FROM DATA SET 
PROCESSOR 1 
CHART JT 




TURN ON FORWARD 

SPACE FILE 

SWITCH 



TURN ON FORWARD 

SPACE FILE 

SWITCH 



TURN ON BACK 

SPACE FILE 

SWITCH 



SET NUMBER OF 

FSF TO 

3(FSQND)-2 



-K3- 



TURN ON RD 

BACKWARDS 

SWITCH, SAVE 

POSITIVE BLK 

CT=NO. RDBCKS 



L 



© 



L 



© 



L 



© 



L 



© 



Section 13: Charts 609 



Chart JO. Restart Data Set Processor lA — Non-Direct Access (Page 2 of 2) 








NO 


Q BACK ■ ^ 


\ 


•'YES 




' 




TURN OFF RD 

BACKWARDS 
SWITCH OFF 






.., ■ 






EXCP READ 
BACKWARD 


G)^ 






^"^ 





L 



© 




WAIT ON ALL 

WORK AREAS TO 

CHECK I/O 

ERRORS 





FREEMAIN DA 



FREE STORAGE 




y ^ 

f DA' 

f PRO! 



D 




-^-C ERROR IN READ 




610 



chart JV. Restart Data Set Processor 2 (Direct Access) 







1 



C— Al s. 
DATA SET ^ 
PROCESSOR 2 j 



FROM SYSIN/SVSOUT 
DATA SET PR0C.2 
CHART JS 




TURN FARM. RLSE 

SWITCH 

OFF-RESTORE 

FULL DISC 

ADDRESS 




BUILD CCW 



1' REPDCB20 



WRITE DSCB 



L 







K(JK 

( RES' 



RESTART EXIT 



) 



DEB UPDATE 



OVERLAY DEB 

CCHH WITH DSCB 

CCHH 



K RES' 



RESTART EXIT 




CLEAR STOR AND 

CONSTR il64 BYTE 

WT. AR, AND 

CONT. BLOCK 



BUILD CCW 



" REPDCB20 



READ DSCB 



CORRECT FILE 

TYPE FROM DD IF 

NECESSARY 



L 








REPDCB76 


^ 


DEB UPDATE 




COMPRESS AND 

REFORMAT DEB, 

UPDATE LENGTH 

OF DEB 


OVERLAY DEB 

CCHH WITH DSCB 

CCHH 





L 







L 







Section 13: Charts 611 



chart JW. Restart Access Method Disposition and Exit 



•" '^' N. 

/ACCESS METHOD^ 
I DISPOSITION 1 



FROM DATA SET 
PROCESSOR 1A OR 2 
CHART JU OR JV 



READ ONE 

DIRECTORY AND 

WAIT 



ANV ERRORS 









ISSUE STOW TO 

DELETE MEMBER 

FROM DIRECTORY 




REPDCB26 w 



RESTORE I/O 



INCREMENT 

POINTER TO NEXT 

DEB 





►f RESTART EXIT j 



RERWTO 


YES 


WRITE RESTART 

UNSUCCESSFUL 

MSG. TO CONSOLE 





/^" ^ 

( ABENDO \ 




FREE RESTART 

WORK AREA 
SUBPOOL = 250 




RESET BLKSIZE 

IN CHKPT DCB TO 

ZERO 




SET RETURN CODE 



D 



612 



Chart JX. TCAM Data Set Processor (Page 1 of 2) 



FROM JFCB 
PROCESSOR 1 
CHART JO 




'■ EP=IGC0V05B 
CHART JW/A5 



OBTAIN 

CHECKPOINT WORK 

AREA 



r~ 7 

/ READ JOB FILE / 
/ CONTROL BLOCK / 



-^ NAME FOUND ^ 
^sX'YES 





MOVE PCB 

ADDRESS FROM 

QCB TO DEB 




INITIALIZE WORK 

AREA WITH DCB 

VALUES 



F3- 

AQCTL 



ISSUE SVC 102 

TO POST ELEMENT 

TO MCP 



U 









MOVE BUFSIZE 
FROM DCBBUFL TO 
TERMTABLE ENTRY 



HOVE BUFSIZE 

FROM PCB TO 

TERMTABLE 



CALC COUNTS OF 

UNITS PER 

BUFFER AND SAVE 

IN PEWA 



L 



B 



Section 13: Charts 613 



Chart JX« TCAM Data Set Processor (Page 2 of 2) 




CHAIN GETSCHED 

STCB TO DEST 
QCB STCB CHAIN 



POST ER3 TO 
DISK I/O QUEUE 




EP=IGC0I05B 
CHART JO/ A 3 



614 



Chaart JY, DOS Tape Data Set Processor (Page 1 of 2) 




TURN ON BYPASS 

CHECKPOINT 
RECORDS SVJITCH 



TURN ON BYPASS 

LEADING 
TAPEMARK SWITCH 



TURN OFF WORK 

AREA BUSY 

SWITCH 





BUILD CCW WITH 

SILI ON, COUNT 

OF TWENTY 




TURN OFF BYPASS 

LEADING 
TAPEMARK SWITCH 




L 












TURN OFF BYPASS 

CHKPT RECORD 

FLAG 



TURN ON BYPASS 

CHKPT RECORD 

FLAG 




Section 13: Charts 615 



Chart JY. DOS Tape Data Set Processor (Page 2 of 2) 



WAIT ON ALL 

WORK AREAS TO 

CHECK I/O 

ERRORS 




^ERROR IN READ_^ 
^NX'YES 



f RES' 



RESTART EXIT 



) 




^B 




'-►FoT 



B 



L 





EXCP REWIND 



^ 







j^LAST READ^S. N' 
^ FORWARD ^- 

^S^YES 



L 



616 



Chart KA. Type-1 SVC Exit 



ttyiNuuu 

(type 



lEAOXEOO 

/reset_type-i 




Section 13: Charts 617 



chart KB, Exit Routine (Page 1 of 3) 



lEAQETOO 



/TYI 



RESET TYPE 1 
SVC SWITCH 
(lEATYPEl ) 




RESET FIRST 

TIME LOGIC 

SWITCH IN PIE 

HOVE REGS FROM 

PIE TO TCB 





L 



B 



SAVE RIGHT HALF 

OF NEXT RE'S 
OLD PSW IN TCB 



RESTORE RB OLD 

PSW: RIGHT HALF 

FROM PIE, LEFT 

HALF FROM SVC 

OLD PSW 




PREPARE REENTRY 

TO RTN IF ANY 
OTHER REQUESTS 




618 



Chart KB, Exit Routine (Page 2 of 3) 




CLEAR TCBSTPPR 

AND SET TASK 
NONDISPATCHABLE 




OBTAIN NEXT RB 
ON QUEUE 



L 







L 








SET RB INACTIVE 

AND REMOVE FROM 

QUEUE 





r 




/fS 



!) 



/ir; 



D 



YES 


FREEMAIN DA 


PROB . PROGRAM 

REGISTER SAVE 

AREA . 
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Chart KB, Exit Routine (Page 3 of 3) 




TAXE PROCESSOR 



PROCESS 

ATTENTION EXIT 

IRB 






EDRQE 



REMOVE ROE FROM 



PUT IQE ON NEXT 

AVAILABLE QUEUE 

IN WORK AREA 



I/O SUPVSR 



RETURN ROE TO 

FREE LIST (NEXT 

AVAIL) 




REINITIALIZE 
IRB FOR REENTRY 
TO ASYNCH. RTN. 



MOVE REGS FROM 
IRB TO TCB'S 
REG SAVE AREA 



r' ^ 

( DISPATCHER j 



Jrtl UNA 

(taxe 





NO 


STATUS 




TASK SWITCH 


START SUBTASKS 


DETERMINE IF 

TASK SWITCH 

NECESSARY 







GET NEXT TAXE 





MAKE TAXE 

AVAILABLE 

INCREMENT STAX 

COUNT 



L 







USE TAIE TO SET 

UP RESUME PSW 

AND REGS 



C RETURN TO \ 
CALLER J 



620 



Chart KC. Transient Area Exit Routine 



IEAQTR33 



V 



D 



FROM EXIT 
ROUTINE 
CHART KB 



lEAQTROl IS USED BY THE EXIT ROUTINE 
WHEN EXIT IS FROM A TYPE 2, 
3, OR 4 SVC ROUTINE. 

TAXEXIT IS USED BY THE 

XCTL PROCESSING ROUTINE 

WHEN AN SVRB IS TO BE REMOVED 

FROM A TRANSIENT AREA QUEUE. 



SAVE CONTENTS 

OF EXITING 

RTN'S REGISTERS 

IN CURRENT TCB 



KEXIT 

r~^' ^ 

( ENTRY \ 

FROM LINK, LOAD, 
XCTL, AND SYNCH 
PROCESSING 
CHART CA 




FIND TRANS AREA 

CTL TEL (TACT) 

ENTRY FOR TAB 

THAT CONTAINS 

THE ROUTINE 



REMOVE 
ASSOCIATED SVRB 
FROM USER QUEUE 



DECREMENT 

TRANSIENT AREA 

USER COUNT 




INDICATE THAT 

TRANSIENT AREA 

BLOCK (TAB) IS 

FREE 



/ RET 
f CA 



1 



Section 13: Charts 621 



Chart KD. Transient Area Refresh Routine 




622 



Chart KE. CDEXIT and CDDESTRY Subroutines 



I EAQETOO 



BRANCH ENTRY 




Section 13: Charts 623 



Chart KF. Dispatcher — Uniprocessing 



lEAQNUOO 





MAKE THE TWO 
WORDS OF TCB 
POINTER EQUAL 



~l 








LOAD REGS 0-15 

FROM CURRENT 

TCB 



FIND RB OF 

HIGHEST 

PRIORITY READY 

TASK 




C— H4 -^ 
LOAD RB PSW A 
FROM lEAPSW j 



SAVE ADDRESS OF 

THIS TCB. GET 
NEXT LOWER TCB 




SET OLD AND NEW 

TCB PTRS TO 

ADDRESS OF 

PSEUDOTCB 



L 



624 



Chart KG. Dispatcher with Job Step and Task Timing (Page 1 of 2) 



lEAQNUOO 
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Chart KG. Dispatcher with Job Step and Task Timing (Page 2 of 2) 








GET NEXT LOWER 

PRIORITY TCB 
FROM TCB QUEUE 




SET 'NEW 

REGISTER SEARCH 

TCB 



SET 'NEW AND 

'OLD' PSEUDO 

TCB 



U 



"-B 



626 



Chart KH. DJSEARCH Subroutine 



r~" ^ 

( ENTRY 1 



FROM DISPATCHER RTN . 
WHEN JOB STEP TIMING 
OPTION IS INCLUDED 




MODIFY INPUT 

TCB SO 

INITIATOR WILL 

BE TIMED 





C RETURN TO "\ 
CALLER j 



REMOVE THE TOE 

FROM TIMER 
QUEUE 




CONVERT TOE TO 

TASK TYPE WITH 

ACTUAL TIME 

REMAINING 




SET INPUT 
OPERATION=NQ 



C RETURN TO \ 
CALLER j 




ENQUE/DEQUE 



f RE' 



) 



Section 13: Charts 627 



Chart KI, Dispatcher with Time Slicing (Page 1 of 3) 



lEAQNUOO 




628 



Chart KI. Dispatcher with Time Slicing (Page 2 of 3) 






GET NEXT TCB IN 

TCB QUEUE AFTER 

T/S GROUP 



IEAQTD01 



TIMER SLIH 



REMOVE T/S TOE 
FROM QUEUE 



L 



IEAQTD01 



TIMER SLIH 



PLACE TOE ON 
QUEUE 



SAVE EMULATOR 

STATUS AND 

ENTER EMULATOR 

MODE 


YES 


/^ CURRENT ^v 
C TASK AN ) 

EMULATOR 

\^rASK 


DSW 


^0 


G3 >-► 

rASK 


Xno 




r 


PLACE FLOAT. 

POINT REGS IN 

OLD TCB 



RESTORE FLOAT. 

POINT REGS. 
FROM ' NEW ■ TCB 




TIMER SLIH 



REMOVE T/S TQE 
FROM QUEUE 



RESTORE 

EMULATOR STATUS 

AND ENTER 

EMULATOR MODE 



Section 13: Charts 629 



Chart KI. Dispatcher with Time Slicing (Page 3 of 3) 



EARCH I 





SET 'NEW AND 

'OLD' EQUAL TO 

PSEUDO TCB 



U 
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chart KJ. Dispatcher with Multiprocessing (Page 1 of 2) 
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Chart KJ. Dispatcher with Multiprocessing (Page 2 of 2) 




632 



Chart KK- DJSEARCH Subroutine with Multiprocessing 



yuu 
( ENTRY j 



SET NQ/DQ 

REGISTER TO 

ZERO 



SET GIVEN TCB 

TO CURRENT TCB 

ON SECOND CPU 




MODIFY INPUT 

TCB SO 

INITIATOR WILL 

BE TIMED 



CONVERT TOE TO 

TASK TYPE WITH 

ACTUAL TIME 

REMAINING 




STORE ADJUSTED 
TIME REMAINING. 

SET NQ/DQ 
REGISTER FOR NO 

OPERATION 



I 



C-Ki ^ 
RETURN TO ^ 
CALLER j 
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Chart KL. Dispatcher with Multiprocessing and Time Slicing (Page 1 of 9) 



/Ml 



lULT I PROCESSING' 

DISPATCHER WITH 

T/S 



IG\ 

y 




SHOULDER TAP 



INTERPT. SEC. 
CPU DIRECT DISP 
TO GAIN CONTROL 



SET 'NEW2' = 

■0LD2' SECOND 

CPU 



0- 



)M\ 
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Chart KL, Dispatcher with Multiprocessing and Time Slicing (Page 2 of 9) 





1— »>roT 



B 



L 
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Chart KL. Dispatcher with Multiprocessing and Time Slicing (Page 3 of 9) 





NO 
1 < 


^ TASK 


HAV?\ 
TQE ^ 


\ 


XV ES 








TIMER ENQ ED 


ADD "NEWT TOE 
TO TQE QUEUE 


1 > 






SET REGISTER 15 
= 



ENQUE JOB-STEP 
TQE 



LOAD 'NEW! ' 

FLOATING-POINT 

REGISTERS 



1— >-roT 



636 



Chart KL. Dispatcher with Multiprocessing and Time Slicing (Page 4 of 9) 







DSCHTSN2 
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chart KL. Dispatcher with Multiprocessing and Time Slicing (Page 5 of 9) 




638 



Chart KL. Dispatcher with Multiprocessing and Time Slicing (Page 6 of 9) 
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Chart KL. Dispatcher with Multiprocessing and Time Slicing (Page 7 of 9) 






DSCHNEW2_^ <|f 




NO 




SET 'NEW2' 


= 







L 
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Chaii: KL. Dispatcher with Multiprocessing and Time slicing (Page 8 of 9) 




Section 13: Charts 6U1 



Chart KL, Dispatcher with Multiprocessing and Time Slicing (Page 9 of 9) 




PICK UP JOB 

STEP 
ORIGINATING 

TASK 




YES 


TIMER DEQ ED 




SET TQEVAL = 
JOB TIME 


REMOVE TOE FROM 
TQE QUEUE 







SET UP TO 
ENQUEUE 



NI TQEFLGS 'FC' 



ENQUEUE/DEQUE 



y' K 

f RE' 



D 



642 



Chart lA, End-Of-Task (EOT) 



lEAQETOO 




STORE 

COMPLETION CODE 

IN TCB 




YES ^ 


FREEMAIN DA 


FREE SPACE 
OCCUPIED BY PIE 





TAXE PURGE 



PURGE TERMINAL 

ATTENTION EXIT 

ELEMENTS 



PURGE TIMER LD 



PURGE ANY 
REMAINING TIMER 
QUEUE ELEMENTS 




ETNQERR 




G 



) 



WTOR PURGE RTN 



PURGE OPERATOR 

COMMUNICATION 

QUEUES 



CLOSE DATA SETS 



CDEXIT RTN 



PREPARE REENTRY 

TO RTN IF ANY 
OTHER REQUESTS 



IF NO OTHER 
REQ'S FOR MODULE, 
EITHER PURGE 
MODULE OR FLAG 



RLSE LOADED PGM LE 



RLSE MAIN STG 



RELEASE 

TASK-RELATED 

SPACE 



-DO- 



SCHEDULE ANY 

END-OF-TASK 

EXIT RTN CETXR) 

THAT IS TO BE 

ENTERED 



REMOVE ENDING 

TASK^S ROLLOUT 

REQUESTS FROM 

ROLLOUT QUEUE 



REMOVE TCB FROM 
TCB QUEUE 



SET TASK 
COMPLETION 
INDICATORS 




YES 


ERASE PHASE RTN 


REMOVE TCB FROM 

SUBTASK QUEUE' 

AND FREE SPACE 





ENSURE THAT A 

TASK SWITCH IS 

INDICATED 



( ^ 

►■( EXIT \ 
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Chart LB, Terminal Attention Exit Eienent Purge 



lEAQETOO 



I TAXE PURGE J 







UPDATE NEXT 

LINK FIELD 

ADDRESS 
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Chart LD. ABEND12 (Page 3 of 3) 
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Chart LV. ABEND13 (Page 1 of 3) 



r~ ^ 

f ABEND 13 j 




SAVE TCB ADDR 

IN ESA £ ZERO 

TJID 




MOVE TCB ADDR 

FROM PREVIOUS 

TO CURRENT 

ABEND SVRB ESA 




QTIP > F4 

TIOT > A5 

TCAM > D3 

NONE— T 



INDICATE FIRST- 
TIME 'ENTRY TO 
TASK SELECT 
ROUTINE 



TAS KSEL 

SELECT 




SET ABEND VALID 

RECURSION FLAG 

ACROSS TCAM 



03 " 


GET TJID IF 

TASK IS A 

FOREGROUND TASK 



/"svc i: 



!) 



©- 



CLEAR ABEND 

VALID RECURSION 

FLAGS 





SET ABEND VALID 
RECURSION FLAG 
ACROSS SVC 101 



GET TJID IF 

TASK IS A 

FOREGROUND TASK 



ISSUE QTIP SVC 




CLEAR ABEND 

VALID RECURSION 

FLAGS 



PURGE 

OUTSTANDING 

ENQ5 



ELIMINATE ABEND 

INDICATOR IN 

ESA 



DEO THIS SVRB £ 

STORE CURRENT 

REGS IN TCB 



DEO SVRB FROM 

RAHSIENT AREA 

HANDLER'S Q 



L 
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Chart LV. ABEND13 (Page 2 of 3) 







1. 



REMOVE THE SVRB 

FROM THE Q 

BEING SCANHED 



TAHABEND 



^B, ^ 

( ENTRY j 




SET TO BEGIN 

SEARCH ON 

TRANSIENT AREA 

REQUEST Q 



-Dl- 



GET DISP OF 

INPUT SVRB 

ENTRY IN 

TRANSIENT AREA 

CNTRL TABLE 





INDICATE THIS 

TRANSIENT AREA 

BLOCK IS FREE 

NOW 



TURN OFF THE 

ACTIVE BIT IN 

THE SVRB 



DECREMENT 
TRANSIENT AREA 
USER COUNT BY- 
ONE 




SET TO BEGIN 

SEARCH ON 

TRANSIENT AREA 

USER Q 



©- 



GET FIRST/NEXT 

SVRB ON THE 6 

BEING SEARCHED 



G 




J 



^VRB ADDR =^ 

(REO Q 
. ONL?) -- 


>=, 






\ 


•n^O 
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■^ SVRB . ^ 
INPUT SVRB 


V NO 




GET NEXT SVRB 
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Chart LV. ABEND13 (Page 3 of 3) 



f ENTRY j 



SET SELECTED 

TCB = DAUGHTER 

OF OUTPUT TCB 




RESET 

FIRST-TIME 

ENTRY INDICATOR 



f RETUl 







SET SELECTED 

TCB = SISTER OF 

OUTPUT TCB 








SET SELECTED 

TCB = MOTHER OF 

OUTPUT TCB 



L 
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Chart LW. ABEND15 (Page 1 of 5) 



lEAQTMOF 



( ABEND! 5 1 



CLEAR ABEND 

VALID RECURS 

FLAGS 



INDICATE FIRST- 
TIME ENTRY TO 
TASK SELECT 
ROUTINE 



©- 



TASKSEL 

SELECT 



LW/5 



SELECT A TASK 

FROM THE 
ABEND I NG TREE 



f ABEND16 1 
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Chart LW. ABEND15 (Page 2 of 5) 



FREEFWA LW/a 


NO 


FREE Mil 

ACQUIRED FETCH 

WORK AREA 





DQRB 



DEQ THE RB IF 

IT DOES NOT OWN 

THE RESOURCE 



~1 



NODQ. 



m 



GET NEXT RB ON 

THE CDE RB 

QUEUE 




© 



a 



LW/4 



RESTART OTHER 
REQUESTORS OF 
THE RESOURCE 



YES 


DQRB LW/3 


NODQ 


QDRBS LVJ/H 


DEQ THE RB IF 
IT DOES NOT OWN 
THE RESOURCE 


RESTART OTHER 
REQUESTORS OF 
THE RESOURCE 







SET DEC 

DECUSE 



DECREMENT THE 

USE COUNT IN 

THE CDE 



DEQD 



DECREMENT THE 

USE COUNT IN 

THE CDE 



-D4- 



TURN OFF SER 
REUSABLE FLAG 

AND TURN ON 
NON- REUSABLE 

FLAG IN CDE 




INDICATE 

FREEMAIN FROM 

SUBPOOL 252 




Li 



B 



L 







'CONDITIONAL 

FREEMAIN * 

SWITCH IN SCVT 



LW/a 



FREE ANY 

ACQUIRED FETCH 

WORK AREA 



PURGE THE CDE 




INDICATE 

FREEMAIN FROM 

SUBPOOL 251 



RESET THE 

' CONDITIONAL 

FREEMAIN' 

SWITCH 



' CONDITIONAL 

FREEMAIN ' 

SWITCH IN SCVT 



Lf 



B 



RESET 

' CONDITIONAL 

FREEMAIN ' 

SWITCH 



©- 



FREE THE EXTENT 

LIST FROM 

SUBPOOL 255 
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Chart tw. ABEND15 (Page 3 of 5) 
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NO 
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Chart LW. ABEND15 (Page 4 of 5) 



QDRBS 




f ENTRY J 



TESTFQRB 



f RETURN \ 



POINT RESUME 

PSW OF QUEUED 

RB TO EP OF 

CDCONTROL 



DECREMENT USE 

COUNT IN CDE BY 

ONE. ZERO CDE 

PTR IN RB 



r^ 


/RB POINT Td\ 


\ 


Xno 



















YES 


TASK SWITCH BN 


CREATE A TSK SW 
USING THE TCB 
OF THE Q'D RB 





L 



© 




'CONDITIONAL 

FREEMAIN' 

SWITCH IN SCVT 



FETCH WORK AREA 

STORAGE FROM 

SUBPOOL 252 



RESET THE 
'CONDITIONAL 
FREEMAIN' SW 



TURN OFF FETCH 

WORK AREA FLAG 

IN RB 



IPFREE ' ' 

r^' ^ 

I RETURN 1 
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Chart LM. ABEND15 (Page 5 of 5) 



( ENTRY \ 



SET SELECTED 

TCB = DAUGHTER 

OF INPUT TCB 




SET SELECTED 

TCB TO INPUT 

TCB 



f RETUl 



SET SEL TCB = 

SISTER OF INPUT 

TCB 








L 
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Chart LX. ABEND16 (Page 1 of 2) 
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chart LX. ABEND16 (Page 2 of 2) 



FREEHAIN DA 


FREE THE RB 


TRR \ 






© 



lil 



REMOVE THE -SEL 

TCB FROM THE 

READY Q 



DEO TCB FROM 
ABENDG TREE £ 
FREE ITS STOR 



i— ►foT 



1^ 



RESET EXIT 

ABEND FLAG IN 

SCVT 



CLEAR THE ABEND 

INDICATOR IN 

THE CURRENT 

ABEND SVRB 




Section 13: Charts 693 



Chart LY. 



ABEND20 



r"' — N 

( ABEND 20 1 



ADD GOOD 

STORAGE IN 

REGION TO 

DYNAMIC FBQE 

CHAIN 



DEQUE AND FREE 
PQE 





INFORM OPERATOR 

STORAGE NOT 

AVAIL 



' ' GMBRANCH 



c 



3 
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Chart MA. DARl 



^., ^ 

( DARl j 
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Chart MB. DAR2 



( DAR2 J 




MOVE JOBNAME 

AND STEPNAME 

INTO MESSAGE 

TEXT 



IEA027I: 

ENQUEUED 
RESOURCES 



0- 

NEXTMAJ 



GET ADDR OF 
NEXT MAJOR QCB 



JEST Ji 



REQ UEST 
WTOR 




IEA028A: REPLY 

CRITICAL (C) OR 

NOT(N} 



WAIT FOR 
OPERATOR 
RESPONSE 



DISABLE 

INTERRUPTS UPON 

RETURN FROM 

WAIT 





CLEAR SVRB ESA 

AND RESET DAR 

RECUR FLAG 



( AB 



D 



a 



GET ADDR OF 
FIRST QEL 
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chart MC. DAR3 (Page 1 of 3) 



c 



1 



MOVE JOBNAME 

AND STEPNAME 

INTO MESSAGE 

TEXT 



MSG RA 

WTO 



" IGC0003E 




GET FIRST 

TRANSIENT AREA 

TASK ADDRESS 



GET FIRST ENTRY 

IN INFORMATION 

LIST 



SET RESUME PSWS 

OF ALL RBS TO 

SVC 3 INSTR 



GET NUMBER OF 

TRANS AREA 
CONTROL TASK 
(TACT) ENTRIES 




CLEAR LOG ECB 




INCREMENT 
NUMBER OF TACT 
ENTRIES BY ONE 




POST MASTER 

SCHEDULER ECB. 

CLEAR TASK 

ACTIVE BIT 



Jl ' 




SET TOP RB PSW 

TO EXECUTE A 

LINK TO 

SCHEDULER WAIT 

RTN 


01 \ 





DECREMENT 
NUMBER OF TACT 
ENTRIES BY ONE 




CLEAR ABTERM 

AND ALL VALID 

RECURSION FLAGS 



SET REG 15 TO 

ABTERM EP AND 

REG 1 TO ROE 

ADDRESS 



SET RESUME PSW 

OF ALL RBS TO 

SVC 3 INSTR 



CI 



J 



POINT TOP RB 

PSW TO ADDR IN 

IEAQTR33 



L 
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Chart MC. DAR3 (Page 2 of 3) 



GET TCB 

REQUESTING RORI 

AND TURN OFF 

ITS RORI BIT 



MC/3 



SET RESUME PSWS 

OF ALL RES TO 

SVC 3 INSTR 



SET RESUME PSWS 

OF ALL RBS TO 

SVC 3 INSTR 



SCHEDULE THE 

TASK REQUESTING 

RORI 





POINT RBOPSW OF 

TOP RB TO EP OF 

lEECVCTB 



G 



u 



E> 



u 




3 



TURN OFF ERROR 

FLAGS IN SVCLIB 
DCB 



GET NEXT 
PREVIOUS RB 

ADDR 



L 




DORQE 







RQE EXIST 



GET FAILING TCB 
ADDR FROM RQE 



POINT SIRE 

RBOPSW TO SVC 3 

INSTR 






POINT TOPRB 
OPSW TO SVC 13 
INSTR AND CLEAR 

WAIT COUNT 



SET REG 1 = RQE 

ADDR FOR 

ERREXCP (SVC 

15) 



CLEAR 'ERROR 

RTN IN PROCESS' 

FLGS IN lOB AND 

TURN ON 

EXCEPTION BIT 
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Chart MC. DAR3 (Page 3 of 3) 



CLEAR SVRB ESA. 

TURN OFF VALID 

RECURS FLG 
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( ENTRY 1 



TURN ON DAR 

VALID RECURS 

FLG 



POINT CURRENT 

RB PSW TO SVC 3 

INSTRUCTION 



( ab: 



3 




NO ^ 


POINT RBOPSW TO 

SVC 3 

INSTRUCTION 






El " 


1 


GET NEXT 

PREVIOUS RB 

ADDRESS 
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Chart MD. DAR4 



r~ ^ 



FROM DART 
DAR2,DAR3 
CHARTS MA, 
MB, MC 





SET DAR WTO 

RECURSION. 

CLEAR BUFFER 

FOR MESSAGE 




MOVE JOBNAME 

AND STEPNAME 

INTO MESSAGE 

TEXT 



NOT IQT 
WTO 



IEA029I: TASK 

BEINSTATEMENT 

FAILED 



TURN OFF DAR 

WTO RECURSION 

FLAG 




GET TOP TCB 

ADDR ON READY 

QUEUE 



SET PRIMARY AND 

SECONDARY NON- 

DISPATCHABILITY 

FLAGS 



IHLMABON: 

RESUME GTF 

TRACE 




0-1 

QSE ARCH ^ 



GET NEXT LOWER 

TCB ON READY 

QUEUE 



( DIS 



y 





SUBSYSTEM PURGE 



SET PRIMARY AND 
SECONDARY NON- 
DISPATCH AB I L I T Y 
FLAGS 



U 







L 
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Chart ME. SVC DUMP 1 (Page 1 of 2) 



lEAQADOY 
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MSKS NON-DISP 

EXCEPT CUMM, 

FETCH, SYS ERR 



INDICATE DUMP 
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TCB) 









^ DEVICE READY 
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SET RETURN CODE 

FOR DEVICE NOT 

SUPPORTED 
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Chart ME. SVC DUMP 1 (Page 2 of 2) 




SET UP CONTROL 

BLOCKS AND CCWS 

FOR READ 



SET UP PTRS AND 
CONTROL BLOCKS 
TO DUMP REQUEST 



HILL DUMP 
ONLY VALID 
PARTS 
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MP TEST RTN 
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MODIFY CONTROL 

BLOCKS IF 

INDICATED BY 

RETURN CODE 






1 






DMPDTAST 






SET APPROPRIATE 
RETURN CODE 


DMPI 


0- 

WTUR 






TURN ON TRACE 
TABLE 



DUMP 

SUCCESSFUL 
OR 
UNSUCCESSFUL 
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Chaart MF, SVC DUMP 2 



IEAQADOZ 




SET UP FOR 

PREFIX! 

BUFFERING 
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Chart MG. Models 91 and 195 Simulator Control Routine 
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Chart MH, Models 91 and 195 Cc»apare Decimal Routine 



/ADD/S UBTKACT/ A 
( ZERO-AND-ADD I 
V DECIMAL J 



f ANALYZER/END 1 




FROM ADD/SUBTRACT/ 
ZERO-AND-ADD 
DECIMAL RTN 
CHART MI 



I ANALYZER/END j 
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chart MI, Models 91 and 195 Add/Subtract/Zero-and-Add Decimal Routine (Page 1 of 2) 



/ADD/S UBTRACT/ ^ 
I ZERO-AND-ADD I 
\^ DEC RTN y 



FROM SIMULATOR 
CONTROL RTN 
CHART MG 



SET SIGNS OF 

OPERANDS IN 

WORK AREA TO 

PLUS 



DETERMINE 

LENGTH OF 

LONGEST OPERAND 



HAKE OP 1 

MINUEND. MAKE 

OP 2 SUBTRAHEND 








CONVERT 


OPERANDS TO 


BINARY 




ADD OPERANDS 

AND CONVERT 

ANSWER TO 

DECIMAL 



MAKE OPERNDl 

WORK AREA PLUS 

ZERO 



PUT SIGN OF 

OPERAND 2 IN 

RESULT SIGN 

SAVE AREA 



► ( ANAl 




ANALYZER/END 



) 








CONVERT 

OPERANDS TO 

BINARY 




CONVERT 4 BYTES 

OF EACH OPERAND 

TO BINARY 






SUBTRACT THE 
CONVERTED 
OPERANDS 




ADD BORROW AND 

SET BORROW 

SWITCH 



SUBTRACT 

SUBTRAHEND FROM 

MINUEND 
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Chart MI. Models 91 and 195 Add/Subtract/ Zero-and-Add Decimal Routine (Page 2 of 2) 



MOVE PARTIAL 
ANSWER TO 
OPERAND 1 







CONVERT a BYTES 

OF EACH OPERAND 

TO BINARY 



i 



CONVERT NEXT H 

BYTES OF EACH 

OPERAND TO 

BINARY 



ADD AND CONVERT 

ANSWER TO 

DECIMAL 









MOVE PARTIAL 
ANSWER TO 
OPERANDI 



CONVERT NEXT 4 

BYTES OF EACH 

OPERAND TO 

BINARY 




MOVE REMAINDER 

OF ANSWER TO 

OPERANDI 




1 



SUBTRACT 

SUBTRAHEND FROM 

MINUEND 




NO 
1- < 


^^IS CARRY ^\ 

^ SWITCH ON ^ 


\ 


^s 










ADD ONE TO 
OPERANDI 


SFA 


,-• 






ADD OPERANDS 

AND CONVERT 

ANSWER TO 

DECIMAL 



MOVE REMAINDER 

OF ANSWER TO 

OPERANDI 



L 
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r 




1 








r^ — ^ 

f ANALYZER/END 1 



-►fcOMPARE DECIHALJ 



r^' ^ 

{ ENTRY j- 

FROM COMPARE 
DECIMAL ROUTINE 
CHART MH 



r~ N 

f ANALYZER/END \ 



NOTE: BORROW AND CARRY 
SWITCHES ARE RESET AT 
TIME OF TESTING. 
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Chart MJ. Models 91 and 195 Multiply Decimal Routine 



CONVERT 4-DIGIT 

GROUPS OF 

0PERAND2 TO 

BINARY 



CONVERT a-DIGIT 
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■ OPERAND 2 TO 
BINARY 
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GROUP OF OPl 
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CONVERT SUMS 

INTO DECIMAL 
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ANALX2ER/END 



) 



MULTIPLY AND 

CONVERT ANSWER 

TO DECIMAL 
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Chart MK. Models 91 and 195 Divide Decimal Routine 
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) 



Section 13: Charts 709 



Chart ML. Models 91 and 195 Analyzer/End Routine 



r~ ^ r' ^ r' ^ r' ^ r' ^ 

f ENTRY J ( ENTRY J f ENTRY j f ENTRY \ f ENTRY J 



FROM SIMULATOR 
CONTROL ROUTINE 
CHART HG 



PLACE 

PROTECTION 

INTERRUPT IN 

PSW 



FROM MULTIPLY 
DECIMAL RTN. 
CHART MJ 



PLACE 

SPECIFICATION 

INTERRUPT IN 

PSW 



FROM DIVIDE 
DECIMAL RTN. 
CHART MK 



PLACE DIVIDE 

CHECK INTERRUPT 

IN PSW 



PROM SIMULATOR 
CONTROL RTN. 
CHART MG 



PLACE 

ADDRESSING 

INTERRUPT IN 

PSW 



FROM 

SIMULATOR 
CONTROL RTN 
CHART HG 
FROM MULTIPL 
DECIMAL RTN 
CHART MJ 



PLACE DATA 

CHECK INTERRUPT 

IN PSW 



U 







L 





C2 ^ A 
ENTRY j 



u 



© 



L 



© 

::nend 

C" s. E 
ENTRY 1 



L 







FROM ADD/SUBTRACT/ 
ZERO-AND-ADD RTN. 
CHART MI 




FROM COMPARE 
DECIMAL RTN 
CHART MH 



PLACE DECIMAL 

OVERFLOW 

INTERRUPT IN 

PSW 




SET UP 

REGISTERS SO 

DATA WILL NOT 

BE RETURNED TO 

PROG. PROG 




( ENTRY \ 

FROM ADD/SUBTRACT 
ZERO-AND-ADD DECIMAL 
CHART MI 

MULTIPLY DECIMAL 
CHART MJ 
DIVIDE DECIMAL 
CHART MK 



MOVE DATA TO 

OPERANDI IN 

PROBLEM PROGRAM 




c 



) 



EJ 

r^" ^ 

I ENTRY J- 

FROM COMPARE 
DECIMAL RTN 
CHART MH 




RETURN TO MODEL 91 
PFLIH RTN. (ENTRY2) 
CHART AG 



^5 ^^ 

►■( EXIT \ 
RETURN TO TESTRAN 



G 



3 



LOAD REGS AND 
RETURN TO 
PROBLEM PROG. 
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Chart MM. System Management Facility EXCP Counter Routine (Page 1 of 2) 



lEAQNUOO 



C-Ai > s. 
SMF EXCP \ 
COUNTER \ 



LOAD TCB PTR 
FROM PASSED TCB 

REG, GET 
CURRENT RB PTR 










SMFEXCPB 



OBTAIN DEB FROK 

DCB AND TCB 

CHAIN 




SMFEXCPC if 




SET ENTRY 

SWITCH. OBTAIN 

TIOT DD ENTRY 

ADDRESS 



OBTAIN LENGTH 

OF DD ENTRY AND 

ADDRESS OF NEXT 

ENTRY 



L 
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Chart MM. System Management Facility EXCP Counter Routine (Page 2 of 2) 



^■ND i 

I " R?-*— 



ADD EACH EXCP 

FIELD: STEP TO 

NEXT 




' © a 



O 




OBTAIN DCB, 

TCT, AND 

INITIALIZE TCB 

ADDRESS 



STORAGE FOR IRB 



INITIALIZE IRB 
STAB/SIZE 



PUT IRB, TCB, 
DCB, AND OUTLIM 
ADDRESS IN IQE 



STG 2 EX EFF BL 



L 



if lEAOABOO 



© 



L 
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chart MN. System Management Facility Time/Output Limit Expiration Routine 



lEAQNUOO 



'SMF TIME/OUTPU' 

LIMIT 

EXPIRATION 



C 



■) 



OBTAIN ADDR OF 
IQE AND TQE 



FOR 72 BYTE REG 

SAVE AREA FROM 

SP253 



PLACE CODE IN 

REG 15 8 = WAIT 

4 = STEP 00 = 

JOBB 



SET UP REGS 1 , 

13 FOR USER 

TIME LIMIT 

ROUTINE 



USER TL ROUTINE 



DET. WHETHER 
TIME LIMIT EXT. 
WILL BE GRANTED 





SET UP FOR 

ABEND WITH 

ERROR CODE 522 



' r lEAOABOO 



SCHEDULE ABEND 



MOVE TIME FIELD 

TO TQE VAL 

SLOT, HARK TQE 

TASK TYPE 



G 




ADD TIME 
EXTENSION TO 
STEP ACC TIME 
FIELD OF TCT 



PUT EXTENSION 
[N TQE AND TURN 

OFF TQE 
COMPLETE FLAG 



TIMER EMQ ED 



PLACE tq: 

QUEO: 




INCREMENT STEP 

TIME OVERFLOW 

FIELD OF TCT BY 

1 



PLACE STEP ACC 

TIME AND 

OVERFLOW FIELDS 

BACK IN TCT 



c 



3 



CONVERT TQE TO 

IRB/IQE FOR 
ASYNCH EXIT RTN 



ST 2 EXT EFF BL 



3 G 



3 
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Chart MO. System Management Facility Wait Time Collection Routine 



lEAQWAIT 



•^ A1 s. 

fSHF WAIT TIME A 
I ENTRY ) 
V COLLECTION J 



FROM EXTERNAL FLIH CHART AH 
FROM INPUT/OUTPUT FLIH CHART AJ 



OBTAIN 

ADDRESSES OF 

CURRENT TCB AND 

PSEUDO WAIT TCB 




NOTE: THIS EXIT IS TAKEN WHEN 
DISPATCHER HAS NOT YET DISPATCHED 
THE WAIT TCB. 



CALCULATE 

EELAPSED WAIT 

TIME FOR THIS 

PERIOD 



■-G1 ' 

ADD ELAPSED 
WAIT TIME TO 

ACCUMULATED 

WAIT TIME AND 

SAVE 



HI " 

PLACE VALUE 
FROM INTERVAL 
TIMER INTO 
SYSTEM WAIT 
START FIELD 



/" RET 
( CA 



3 
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SECTION It; PROGRAM ORGANIZATION 



This section is designed to help the reader understand the relationships among super- 
visor routines and to aid the reader in locating the routines in the program listings. 
It includes a module directory, a directory of entry point names and flowchart IDs, a 
table of routines invoked by SVC instructions, and synopses of supervisor routines. 

MODDLE DIRECTORY 

The module directory contains structural information about each routine. The direc- 
tory is arranged in alphameric order by entry point names. The directory should be used 
to locate modules and control sections for supervisor and related routines. 



LEGEND; 

LIBRARY CODES 

LINK = SYSl.LINKLIB Data Set 
NUC = SYSl. NUCLEUS Data Set 
SVC = SYSl.SVCLIB Data Set 

SECTION CODES 

CCSL = Console Communications and System Log 

CR = Checkpoint/Restart 

CS = Contents Supervision 

EP = Exiting Procedures 

IH = Interruption Handling 

MSS = Main Storage Supervision 

SF = Special Features 

TMS = Timer Supervision 

TP = Termination Procedures 

TS = Task Supervision 

Note 1 ; e.p. = entry point 

Note 2 ; Blank items in chart are not applicable. 
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r 1 

1 

1 Entry 
1 Point 
1 Name 


Name of Routine, Control Block, 
Table, Transient Area 


Module 
Name 


r — — 1 

Control 

Section 

Name 

1 


r - - - 1 
PLH 
References 

_, 




Lib. 


r — 1 

Section 

1 1 


r n 

Chart 

ID 


1 CDADVANS 


Contents Supervision common 
subroutines (search phase) 


._ 

lEAQLKOO 


lEAQLKOO 


1 ^ 

cs 






CA 




NOC 


1 CDCONTRL 
jalso 
1 called 
1 IEAQCS02 


Contents Supervision common 
subroutines (search phase) 


lEAQLKOO 


lEAQLKOO 


cs 


CA 


NUC 


1 CDDESTRY 


CDEXIT routine 


lEAQETOO 


IGC003 


EP.TP 


KE 


NUC 


1 CDEPILOG 


Contents Supervision common 
subroutines (scheduling phase) 


lEAQLKOO 


lEAQLKOO 


cs 


CA 


NUC 


1 CDEXIT 


CDEXIT routine 


lEAQETOO 


IGC003 


EP 


KE 


NUC 


1 CDHKEEP 


CDEXIT routine 


lEAQETOO 


IGC003 


EP.TP 


KE 


NUC 


|EOT 


End-of-Task (EOT) routine 


lEAQETOO 


IGC003 


TP 


LA 


NUC 


1 ERFETCH 


Stage 3 Exit Effector 


lEAQNUOO 


lEAQNUOO 


TS 


BM 


NUC 


1 FLASH 


First CPO Signal routine 


lEAQFXOO 


lEAQFXOO 


TS 




NUC 


1 FMBRJtflCH 


FREEMRIN routine (branch e.p. ) 


lEAQGMOO 


lEAQGMOO 


MSS 


DA 


NUC 


1 FMSMFCRE 


SMF Storage routine 


lEAQGMOO 


lEASMFGF 


SF 


DA 


NUC 


1 FTCEOl 


Program Fetch Channel-End 
Appendage routine 


lEWFETCH 


lEWFETCH 


CS 


CD 


NUC 


IFTPCIOl 


Program Fetch PCI Appendage 
routine 


lEWFETCH 


lEWFETCH 


cs 


CD 


NUC 


1 GETIQE 


GETMAIN routine (branch e.p. 
to the GETIQE subroutine) 


lEAQPRTO 


lEAQPRTO 


CS 


DA 


NUC 


1 GETPART 


GETMAIN routine (branch e.p. 
for request to allocate a 
region) 


lEAQPRTO 


lEAQPRTO 


MSS 


DA 


NUC 


1 GMBRANCH 


GETMAIN routine (branch e.p.) 


lEAQGMOO 


lEAQGMOO 


MSS 


DA 


NUC 


1 GMSMFCRE 


SMF Storage routine 


lEAQGMOO 


lEASMFGF 


SF 


DA 
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Repmain H 

DDRMSG M0D#2 

ABEND routine (ABEND9) 

Repmain 5 

Communications Task 

NIP Message Buffer Writer 

Communications Task Card 
Reader Open/Close routine 

Communications Task Card 
Reader Processor routine 

Communications Task Card 
Reader Processor (MCS) 

Communications Task 
Printer Open/Close routine 

Communications Task 
Printer Processor routine 

Communications Task 
Printer Processor (MCS) 

Wait routine 

Post routine 

Post routine (branch e.p. from 
supervisor routines) 



Exit routine 
X 



T- 



Module 
Name 



IEAQTM05 
IEAQAD05 
IGC0505B 
IGC0506C 
IGC0508E 
IEAQAD06 
IGC0605B 
IGC0608E 
IEAQTM07 
IEAQAD07 
IGC0705B 
IGC0708E 
IEAQTM08 
IEAQAD08 
IGC0805B 
IGC0808E 
IEAQTM09 
IGC0905B 
lEECMWTL 

lEECVOCC 

lEECVPMC 

lEECMPMC 

lEECVCXIP 

lEECVPMP 

lEECMPMP 

IEAQSY50 
IEAQSY50 
lEAQSySO 

lEAQETOO 



Control 

Section 

Name 



IGC0501C 
IGC0505A 
IGC0505B 
IGC0506C 
IGC0508E 
IGC0605A 
IGC0605B 
IGC0608E 
IGC0701C 
IGC0705A 
IGC0705B 
IGC0708E 
IGC0801C 
IGC0805A 
IGC0805B 
IGC0808E 
IGC0901C 
IGC0905B 
IGC0907B 

lEECVOC 

lEECVPM 

lEECVPM 

IEECVOC 

lEECVPM 

lEECVPM 

IGCOOl 
IGCOOl 
IGCOOl 

IGC003 



+- 



PLH 
References 

1 Chart 



Section 



TP 

TP 

CR 

CR 

* 

TP 

CR 

* 

TP 

TP 

CR 

* 

TP 

TP 

CR 

TP 
CR 
CCSL 

CCSL 

CCSL 

CCSL 

CCSL 

CCSL 

CCSL 

TS 
TS 
TS 

EP 



ID 



LP 
LI 
JK 

JD 

LI 
JL 

LQ 
LI 
JM 

LR 
LI 
JM 

LS 
JN 
FP 



(Fig. 
7-2) 

FU 



FV 



(Fig. 
7-1, 
7-2) 

(Fig. 
7-1, 
7-2) 



EG 
BH 
BH 

KB 



Lib. 



SVC 
SVC 
SVC 
SVC 
SVC 
SVC 
SVC 
SVC 
SVC 
SVC 
SVC 
SVC 
SVC 
SVC 
SVC 
SVC 
SVC 
SVC 
SVC 

SVC 

SVC 

SVC 

SVC 

SVC 

SVC 

NUC 
NUC 
NUC 

NUC 



If SVC Routine 



Type 



T r 

Macro 
Instruction 



1 

,X i 



WAIT 
POST 



SVC 
Instr. 



SVC 13 
SVC 51 
SVC 52 
SVC 63 
SVC 85 
SVC 51 
SVC 52 
SVC 85 
SVC 13 
SVC 51 
SVC 52 
SVC 85 
SVC 13 

SVC 52 
SVC 85 
SVC 13 
SVC 52 
SVC 72 

SVC 72 

SVC 72 

SVC 72 

SVC 72 



SVC 72 

SVC 1 
SVC 2 



SVC 3 
1 J 



Figure 14-1. Module Directory (Part 11 of 17) 



(See legend before Part 1 ) 
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^- 



Entry 
Point 
Name 



IGC004 
IGC005 
IGC006 

IGC007 

IGC008 

IGC009 
IGCOIO 

IGCOll 
IGC012 

IGCOIU 
IGC016 

IGC037 



IGCOUO 
IGCOUO+8 

IGCOll 

IGC0U2 

IGC0U3 

IGCOUU 
IGCOUIJ 
+12 

IGC0«5 



IGC046 
IGC047 
IGC0U8 
IGC056 
IGC061 
IGC062 



Name of Routine, Control Block, 
Table, Transient Area 



GETMAIN routine 

FREEMAIN routine 

Contents Supervision, conunon 
subroutines (e.p. for the LINK 
macro instruction) 

Contents Supervision, common 
subroutines (e.p. for the XCTL 
macro instruction) 

Contents Supervision, common 
subroutines (e.p. for the LOAD 
macro instinaction) 

Delete routine 

GBTMAIN/FREEMAIN routines 
(e.p. for R-form macro 
instructions) 

Time routine 

Contents Supervision, common 
subroutines (e.p. for the 
SYNCH macro instruction) 

SPIE routine 

SVC Purge routine 



Overlay Supervisor, resident 
module (e.p. for a SEGLD or 
SEGWT macro instruction) 

Extract routine 

Extract routine (branch e.p.) 

Identify routine 

Attach routine 

Stage 1 Exit Effector 

CHAP routine 

CHAP routine (branch e.p.) 

Overlay Supervisor, resident 
module (e.p. for branch 
instruction or CALL macro 
instruction) 

TTIMER routine 

STIMER routine 

Dequeue routine 

Enqueue routine 

TESTRAN interpreter 

Detach routine 



Module 
Name 



lEAQGMOO 
lEAQGMOO 
lEAQLKOO 

lEAQLKOO 

lEAQLKOO 

lEAQLKOO 
lEAQGMOO 

lEAQRTOO 
lEAQLKOO 

lEAQTBOO 

IECIPR16 
macros 

lEWSUOVR 

lEAQTBOO 

lEAQIDOO 
lEAQATOO 
lEAQEFOO 
lEAQCHOO 

lEWSVOVR 

lEAQSTOO 
lEAQSTOO 
IEAQENQ2 
IEAQENQ2 
IGC0006A 
IEAQED02 



Control 

Section 

Name 



T T 

PLM 
References 



lEAQGMOO 
lEAQGMOO 
lEAQLKOO 

lEAQLKOO 

lEAQLKOO 

lEAQLKOO 
lEAQGMOO 

IGCOll 
lEAQLKOO 

IGCOIU 
IGC016 

IGC037 

IGCOIU 

IGCOUl 
IGC0U2 
IGCOHB 
IGCOHH 

IGC037 

IGC046 

IGCOUe 

IGC048 

IGC048 

lEGHRSAV 

IGC062 



Section 



MSS 
MSS 
CS 

CS 

CS 

CS 
MSS 

TMS 
CS 

TS 
MSS 

CS 

TS 

CS 
TS 
TS 
TS 

CS 

TMS 

TMS 

TS 

TS 

CS 

TS 



Chart 
ID 



■{Lib. 



DA 
DA 
CA 

CA 

CA 

CC 
DA 

EA,EE 
CA 

BF 

CE 

BD 

CB 
BA 
BK 
BB,BC 

CE 

EC, EG 
EB.EF 
BJ 
BI 

BE 



NUC 
NUC 
NUC 

NUC 

NUC 

NUC 
NUC 

NUC 
NUC 

NUC 
NUC 

NUC 

NUC 

NUC 
NUC 
NUC 
NUC 

NUC 

NUC 
NDC 
NUC 
NUC 
SVC 
NUC 



If SVC Routine 



Type 



Macro 
Instruction 

GETMAIN 

FREEMAIN 

LINK 

XCTL 

LOAD 



DELETE 

GETMAIN (R) 
FREEMAIN (R) 



TIME 
SYNCH 



SPIE 
PURGE 



SEGLD 
SEGWT 



EXTRACT 

IDENTIFY 
ATTACH 
CIRB 
CHAP 

CALL 

TTIMER 

STIMER 

DEQ 

ENQ 

TTSAV 

DETACH 



SVC 
Instr 
— — H 
SVC u 

SVC 5 

SVC 6 



SVC 7 

SVC 8 

SVC 9 
SVC 10 

SVC 11 
SVC 12 

SVC in 
SVC 16 

SVC 37 

SVC UO 

SVC 41 
SVC «2 
SVC 43 
SVC 44 

SVC 45 

SVC 46 

SVC 47 

SVC 48 

SVC 56 

SVC 61 

SVC 62 



Figure 14-1. Module Directory (Part 12 of 17) 
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1— 1 

1 Entry 

1 Point 

Name 


r - - — -1 

Name of Routine, Control Block, 
Table, Transient Area 


r — 1 

Module 
Name 

L j 


r — - T — i— - 

1 PLM 1 
Control 1 References | 

Section j— ^ r ^Lib. 

Name | j Chart j 

1 Section 1 ID | 

L . .. . i ' < 


T - ■ 


1 
If SVC Routine | 

1 


1 1 Macro 1 SVC 1 

I Type 1 Instruction j Instr . | 

II II 


i IGC079 


Set Status routine 


lEAQSETS 


lEAQSETS 1 


TS 


|BW 


|NOC 

1 


1 1 


[STATUS |SVC 79 1 


IIGC109 


Extended SVC Router Types 
3 and U 


IGC116 


IGC116 1 
1 

1 


IH 


|AC 


1 
|SVC 

1 

1 


1 2 


1 ISVC1091 


1 IGC116 


Extended SVC Router Type 1 


IGC116 


1 
IGC116 I 


IH 


|AC 


1 

|SVC 

1 


1 1 


1 |SVC116| 


1 IGC117 


Extended SVC Router Type 2 


IGC116 


IGC116 1 


IH 


|AC 


1 

|SVC 
1 


1 2 


1 |SVC117| 


|IGE0660A 


DDR Central 


IGE0660A 


IGE0660AI 


* 




1 
isvc 

I 






IIGFASROB 


CPU Analysis module 


IGFASROB 


IGFASROB 1 
1 






|SVC 
1 






1 IGFASROC 


Instruction Retry Analysis 
module, phase 1 


IGFASROC 


1 

IGFASROC I 

1 






1 

SVC 
1 






1 IGFASROD 


Storage Protection Feature 
Test module 


IGFASROD 


1 

IGFASROD 1 

1 
1 






1 

|SVC 

1 

1 






IIGFASROO 


System Analysis module 
for the Model 65 


IGFASROO 


1 

IGFASROO 1 

1 






1 

|SVC 

1 

1 






1 IGFASROl 


MCH Error Recorder module 


IGFASROl 


1 
IGFASROl 1 






1 

|SVC 
1 






1 IGFASRIA 


Refresh Clear Channel module 


IGFASRIA 


IGFASRIA 1 

1 






1 

|SVC 

1 






1 IGFASRIC 


Instruction Retry Analysis 


IGFASRIC 


1 

IGFASRIC 1 

1 






1 

|SVC 

I 






1 IGFASRID 


Error Check Circuitry Verifi- 
cation module 


IGFASRID 


1 

IGFASRID! 






1 

|SVC 

1 

1 






IGFASRIO 


Refresh Loader module 


IGFASRIO 


IGFASRIO 1 






1 

|SVC 

1 






1 IGFASR2C 


Instruction Retry Execution 
module, phase 1 


IGFASR2C 


IGFASR2C 1 
1 






1 
jsvc 

1 

1 






1 IGFASR2D 


Main Storage Scan module 


IGFASR2D 


IGFASR2DI 

1 






jsvc 

I 






1 IGFASR20 


PDAR Termination Analysis 
module 


IGFASR20 


1 

IGFASR20 1 






1 

SVC 

1 






1 IGFASR3C 


Instruction Retry Execution 
module, phase 2 


IGFASR3C 


IGFASR3C 1 
1 






1 
jsvc 

1 

1 






1 IGFCAT 


Channel-Check Handler 
Central (CCH) 


IGFCATAP 


IGFCAT 1 

1 
1 


IH 




1 

|NUC 

1 

1 






1 IGFCCH48 


CCH 155 Analysis Module 


IGFCCH48 


1 
IGFCCH48 I 






1 

|NUC 

1 






1 IGFCCH60 


CCH 2860 Analysis Module 


IGFCCH60 


IGFCCH60I 
1 






1 

|NUC 






1 IGFCCH68 


CCH 145 Analysis Module 


IGFCCH68 


1 
IGFCCH68 1 






NUC 

1 






1 IGFCCH70 


CCH 2870 Analysis Module 


IGFCCH70 


IGFCCH70 1 
1 






1 

INUC 
1 






1 IGFCCH80 


CCH 2880 Analysis Module 


IGFCCH80 


1 

IGFCCH80 1 






1 

jNOC 
1 






1 IGFDDRSR 


DDR SYSRES Module 


IGFDDRIO 


IGFDDRSR 1 


* 




1 

|NUC 
1 






1 IGFDDROl 


DDR Resident Module 


IGFDDRMV 


IGFDDROl 
i 


+ 




1 
|NUC 

1 






IIGFDDR02 

L _ J 


DDR Channel End Appendage 

L_ _ _ _ J 


IGFDDR02 




1 

IGFDDR02 1 
L X. 


* 


_x 


1 
|NUC 

^x 


X 


.X L J 


1 tRoutine 


discussed in I/O Supervisor PLM 


GY28-66' 


16. 










- _ J 



Figure 14-1. Module Directory (Part 13 of 17) 
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r T — - - 1 

1 1 
1 Entry | 


r r r 

1 PI 
Control 1 Refere 

MfV^Til^ opc^-T/in L___^___ 


r r 1 

.H 1 1 1 
nces 1 1 If SVC Routine | 


1 Name | Table, Transient. Area 

1 1 
I 1 


Name j Name | 

1 1 Sectior 


-]- 1 Ilia, Y - T : 1— r ■\ 

j Chart! 1 I Macro j SVC j 

1 1 ID 1 1 Type 1 Instruction j Instr . j 
J. _j i i 4- -i 


r 1 

1 IGFDDR03|DDR Abnormal End Appendage 
1 1 


IGFDDR03|1GFDDR03| * 


1 lirac II II 


1 1 

1 IGFDDR05 1 DDR SYSRES Module 

1 1 

i 1 

1 1 
1 1 


IGFDDR10|IGFDDRSR| * 
IGFDDROO I IGFDDRSRJ 
(without 1 1 
MCS) I 1 


1 |NUC 1 1 1 


1 1 

1 IGFMCHEO 1 MCH Nucleus 

1 1 


IGFMCHEO 1 IGFMCHEO | 




1 1 

1 IGFMCHEl 1 MCH Console Write Module 

1 jfor System/370 

1 1 


IGFMCHEl 1 IGFMCHEl | 


1 |svc II II 


1 IGFMCHE2 1 MCH Error Recorder Module 
1 |for System/avo 
1 1 


IGFMCHE2 1 IGFMCHE2 | 


1 |svc 1 1 1 


1 1 

|IGFMCHE3|MCH Emergency Error Recorder 
1 1 Module for System/370 
1 1 


IGFMCHE3 1 IGFMCHE3 | 


1 jsvc 1 1 j 


1 IGFMCHFO 1 MCH Initialization Module for 
1 1 System/ 360 Model 85 and 
1 1 System/370 
1 1 


IGFMCHFO 1 IGFMCHFO | 


1 \svc II II 


1 IGFMCHFU 1 Refresh Loader Module for 
1 1 System/360 Model 85 
1 1 


IGFMCHF4 I IGFMCHFI | 


1 |svc II II 


1 IGFMCHF5 1 PDAR Terminator Analysis 
1 jfor System/360 Model 85 
1 jand System/370 


IGFMCHF5 IGFMCHF5I 


1 |svc II II 


|IGFMCHF6 Subsystem Interface Module 
1 jfor System/370 Model 165 
1 1 


IGFMCHF6 1 IGFMCHF6 | 


1 |svc II II 


1 1 

1 IGFMCH13 1 Preliminary Error Analysis 

1 1 Module for System/360 Model 85 

1 1 


IGFMCH13 1 IGFMCH13 | 


1 |svc II II 


1 1 

1 IGFMCHlt 1 Repair Refresh Verification 
1 [Module for System/360 Model 85 
1 1 


IGFMCHll* 1 IGFMCHIU \ 


|svc II II 


IIGFMCH15 Storage Protect Feature 
1 Analysis Module for 
j 1 System/360 Model 85 
1 1 


IGFMCH15 1 IGFMCH15 | 


1 |svc II II 


1 XGFMCH16 1 Buf f er Control Module 


IGFMCH16 1 IGFMCH16 | 


1 |svc II II 


IIGFMCH17 Error Recorder Module for 
1 System/360 Model 85 
1 1 


IGFMCH17 1 IGFMCH17 | 


1 |svc II II 


1 IGFMCH18 1 Alternate Multiply Control 

1 1 Module for System/360 Model 85 

1 1 


IGFMCH18|IGFMCH18| 


1 |svc II II 


1 IGFMCH19 1 Main Storage Analysis Module 

1 |for System/360 Model 85 
1 1 


IGFMCH19 1 IGFMCH19 | 


1 |svc II II 


1 1 

|IGFMCH20|Soft Machine-Check Handler 
1 jfor System/370 Model 155 
1 1 


IGFMCH20I IGFMCH20 | 


1 jsvc II II 


1 1 

1 IGFMCH21 1 Main Storage Analysis Module 

1 jfor System/370 Model 155 


IGFMCH21 i IGFMCH21 | 


1 |svc 1 1 1 


|IGFMCH22 Storage Protect Feature 
1 1 Analysis Module for 
1 1 System/370 Model 155 


IGFMCH22 1 IGFMCH22 | 


1 JSVC 1 1 1 
! 1 1 1 II 



I *Routine discussed in I/O Supervisor PLM, GY28-6676. 



Figure m-l. Module Directory (Part 14 of 17) 
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1 Entry | 

1 Point jNcune of Routine, Control Block, 

1 Name j Table, Transient Area 


T ~( PI 
(Control ( Refere 


— __,_ __p — 

>M ( 1 
nces ( ( 

1 T -i hi L 


If SVC Routine ( 


nuuuxtf 1 oecrciun r— — — — 
Name j Name j 

j (Section 


-T— — — ^ljiU« f— — 

( Chart ( ( 
( ID ( (Ty 


1 Macro ( SVC ( 

pe( Instruction! Instr. ( 

1 , 1 .. J 


1 IGFMCH23 1 Repair/Refresh Verification 

1 1 Module for Systein/370 Model 155 


IGFMCH23 1 IGFMCH23 ( 
i 1 


( (SVC ( 


T r 1 


1 IGFMCH30 1 Sof t Machine-Check Handler 
1 jfor Systein/370 Model 165 


1 1 
IGFMCH30 I IGFMCH30 j 


( (SVC ( 




1 IGFMCH31 1 Preliminary Error Analysis 

1 (Module for System/370 Model 165 


IGFMCH31|IGFMCH31( 


1 |SVC ( 




IGFMCH33 1 Main Storage Analysis Module 
1 jfor System/370 Model 165 


IGFMCH33 ( IGFMCH33 ( 


( (SVC ( 




1 IGFMCH34I Storage Protect Feature 
1 (Analysis Module for 
1 1 Systein/370 Model 165 


IGFMCH3« 1 IGFMCH3U ( 


( |SVC ( 




1 IGFMCH35 1 Repair/Refresh Verification 
1 1 Module for System/370 
1 (Model 165, Part 1 


IGFMCH35( IGFMCH35 j 


( (SVC 1 




( IGFMCH36 (Repair/Refresh Verification 
i (Module for System/370 
( (Model 165, Part 2 


IGFMCH36 ( IGFMCH36 ( 


( (SVC ( 




(IGFMCHUO Soft Machine-Check Handler 
( for System/370 Model 1U5 


IGFMCHUO 1 IGFMCHUO | 


1 |SVC ( 




( IGFMCHIl ( Preliminary Error Analysis 
( (for System/370 Model 1H5 


IGFMCHUl ( IGFMCHiH ( 


( (SVC ( 




( IGFMVTFl ( System Analysis Module for 
( (System/360 Model 85 and 
( (System/ 370 


IGFMVTFl 1 IGFMVTFl ( 


( |svc ( 




(IGFMVTF2 (System Analysis Module for 
( (System/360 Model 85 and 
( (System/ 370 


IGFMVTF2 ( IGFMVTF2 ( 


( (SVC ( 




( IGFMVTF3 j System Analysis Module for 
1 (System/360 Model 85 and 
( (System/ 370 


IGFMVTF3 ( IGFMVTF3 ( 


( (SVC 1 




(IGFN0000(MCH Resident Nucleus for 
( i System/360 Model 65 
( i System/360 Model 85 
j (System/370 


IGFNHCOO ( IGFNOCOO ( 
IGFMCHIO ( IGFMCHIO ( 
IGFMCHEO ( IGFMCHEO 


( NUC ( 
1 (NUC ( 
j jLINKJ 




(IGFNOOOljConsole/SYSRES Clear Channel 

( (Module for 

( 1 System/360 Model 65 

( (System/360 Model 85 


IGFASROA IGFASROA( 
IGFASR5A IGFASRSAJ 


1 |svc ( 

( (SVC ( 




(IGFN0002(MCH Termination Module for 
( (System/360 Model 65 
( 1 System/360 Model 85 


IGFASROA IGFASROA 1 
IGFMCH12 IGFMCH12( 


( (SVC ( 

( |svc 1 




(IGFO 85 01 (Machine Status Control Module 
( (Part 1 for System/360 Model 85 


IGF08501(IGF085011 


( |svc ( 




(IGFO 85 02 (Machine Status Control Module 
j [Part 2 for System/360 Model 85 


IGF08502(IGF08502( 


( |svc [ 




(IGF29601( Machine Status Control 

( (Module for System/370 Model 155 


IGF29601(IGF29601( 


( (SVC ( 


1 1 1 



Figure 14-1. Module Directory (Part 15 of 17) 
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r 

Entry 
Point 
1 Name 


r - - - ■■ 1 

Name of Routine, Control Block, 
Table, Transient Area 


i Control 
Module 1 Section 
Name | Name 


PLM 
References 


r— -1 — - — • 1 

1 1 
1 If SVC Routine | 

T.i K 1 __- 1 


r r 

Section 


1 
Chart 
ID 

L J 


1 

IType 


Macro 1 SVC 1 
Instruction j Instr . 
1 


1 IGF29701 


Machine Status Control 
for System/370 Model 145 


IGF29701|IGF29701 


1 


1 


SVC 1 

1 




IIGF2403D 


APR VARY PATH Comnand Processor 


IGC2l|03D|IGF2l(03D 


♦ 




SVC 1 

1 




IIGF211MPD 


APR VARY PATH Command 
Processor (Load 1 MP) 


IGC2U03DI IGF24MPD 

1 


* 




1 
SVC I 

1 




IIGF2503D 


DDR SWAP Command Processor 


IGC2503D1IGF2503D 


* 




SVC 1 

f 




IIGF34MPD 


APR VARY PATH Command 
Processor (Load 2 MP) 


IGC3H03DI IGF34MPD 


* 




1 
SVC 1 




IIGF55301 


Machine Status Control 

Mod\iLe for System/370 Model 165 


IGF29701|IGF29701 






SVC 1 

1 




1 INTEXTRN 


Second CPU Interruption 
Analysis routine 


lEAQFXOO 1 lEAQFXOO 


IE 




NUC 1 




IINTMLFAL 


Second CPU Recovery Management 
System Interface routine 


lEAQFXOO 1 lEAQFXOO 


IH 




NUC 1 




1 INT025A 


Routine in the I/O Supervisor 
that returns a request element 
to the free list 


lEAQFXOO 1 lEAQFXOO 
(lEAQFX 1 
and 1 
lECIOS 1 
macros) j 


EP 




NUC 1 




1 lORGSW 


I/O Switch (in I/O First-Level 
Interruption Handler) 


IEAQNU02 1 IEAQNU02 
1 


IH 




NUC 1 




1 LINKDCB 


Data Control Block (DCB) for 
the SYSl.LINKLIB data set 


1 
lEAQBKOO 1 lEAQBKOO 






NUC 1 




1 LINKDEB 


Data Extent Block (DEB) for the 
SYSl.LINKLIB data set 


lEAQBKOO 1 lEAQBKOO 






NUC 1 




1OVIALD02 


SEGLD Processor routine 


lEWSWOVRI lEWSWOVR 
1 


CS 


CE 


LINKI 




jRMBRANCH 


GETMAIN/FREEMAIN routines 
(branch e.p. ) 


1 

lEAQGMOO lEAQGMOO 


MSS 


DA 


NUC 1 1 




1 SECMCI 


SERO routine 

System/360, Model HO 
System/360, Model 50 
System/360, Model 65 
System/360, Model 75 


1 
IFBSR040 IFBSR040 
IFBSR050 IFBSR050 
IFBSR065|IFBSR065 
IFBSR075 1 IFBSR075 


IH 
IH 
IH 
IH 


AK 
AK 
AK 
AK 


LINKI 
LINKI 
LINKI 
LINKJ 




1 START 


Initial Program Loading routine 


lEAIPLOOjIEAIPL 
1 










1 SVCDCB 


Data Control Block (DCB) for 
the SYSl.SVCLIB data set 


1 
lEAQBKOO 1 lEAQBKOO 

1 






NUC 1 




1 SVCDEB 


Data Extent Block (DEB) for the 
SYSl.SVCLIB data set 


lEAQBKOO 1 lEAQBKOO 
1 






NUC 1 




ITABLDL 
j TAHFETCH 


Transient Area Fetch routine 


1 
IEAQTR33 | lEAQTROO 


IH 


AE 


NUC 1 




1 TAIOBl 
|T7U:OB2 
1 TAIOBn 
1 TAIOBn+1 


Transient area I/O blocks 
(lOBs) and associated transient 
areas 


lEAQBKOO lEAQBKOO 

1 






NUC 1 
1 





j *Routine discussed in I/O Supervisor PLM, GY28-6676. 
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Figure 11-1. Module Directory (Part 16 of 17) 
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r — 1 

1 

1 Entry 

1 Point 

1 Name 

1 


1 1 1 

1 1 control 1 

Name of Routine, Control Block, | Module j Section j- 

Table, Transient Area j Name | Name | 

1 1 1- 

L , . . , III 


PLM 1 
References | 


T- ■ 

1 

1 If SVC Routine 


-1 


1 Chart j 
Section | ID | 

_ Li 


1 1 Macro 1 SVC 
Type Instruction! Instr 


1 
1 


! TASEARCH 


Transient Area 


XCTL routine | IEAQTR33 | lEAQTROO | 


CS 


r 1 

1 CA 1 NUC 




1 


1 TATABCK 
1 


Transient Area 
Check routine 


Availability 


1 1 

IEAQTR33 j TEAQTROO j 
1 1 


IH 


1 1 

1 AD 1 NUC 

1 1 






1 

1 TAX EXIT 


Transient Area 


Exit routine 


1 1 
IEAQTR33 1 lEAQTROO 1 


EP 


1 1 
|KC JNUC 






1 TAXRETRY 


Transient Area 


XCTL routine 


1 1 

IEAQTR33 j lEAQTROO | 


CS 


1 1 
|CA |NUC 






1 

jTESTDSP 

1 


Task Removal routine 


1 1 

lEAQFXOOJ lEAQFXOO j 

1 1 


IH 


1 1 

1 |NUC 

1 1 






1 

1 TRDISP 

1 


Trace routine 


(e.p. for the 
Dispatcher) 


1 1 

lEAQTRCE 1 lEAQTRCE j 

1 1 




1 1 

1 I NUC 

1 1 






|TREX 

1 
1 


Trace routine 


(e.p. for Ext. 
FLIH) 


lEAQTRCE 1 lEAQTRCE | 
1 1 




1 |NUC 
1 1 






1 
|TRIO 

1 
1 


Trace routine 


(e.p. for I/O 
FLIH) 


1 1 
lEAQTRCE 1 lEAQTRCE | 

1 i 




1 1 

1 |NUC 

1 1 






1 
|TRPI 

1 


Trace routine 


(e.p. for PC 
FLIH) 


1 1 

lEAQTRCE I JEAQTRCE j 

1 1 




1 1 

1 INUC 

1 1 






1 TRSVC 

1 
1 


Trace routine 


(e.p. for SVC 
FLIH) 


1 1 

lEAQTRCE 1 lEAQTRCE | 

1 1 




1 1 

j INUC 

1 1 






1 

1 USERORG 

1 


SVC table (start of user- 
assigned SVC numbers) 


1 1 

lEAQBKOO I lEAQBKOO 

1 
L X X. 


IH 


1 1 

1 |NUC 

1 1 


.X J J 


-J 
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Name of Routine, Control Block, Table, Transient Area 



ABDUMP routines 

"resident" module 

ABDDMPl 

ABD0MP1.5 

ABD0MP2 

ABDOMP3 

ABDUMP<( 

ABD0MP5 

ABDUMP6 

ABDUMP7 

AB00MP8 

ABDUMP9 

ABDOMPIO (resident routine) 

ABDDMPll 

ABDDMP12 

ABD0MP13 

ABD0MP14 

ABD0MP15 

ABDDMP16 

ABDDMPQ 

TCAM ABDUMP 1 

TCAM ABDOMP 2 

TCAM ABDOMP 3 

TCAM ABDOMP 4 

ABDDMPH 

ABDDMPl 

SVC DOMP 1 

SVC DOMP 2 

ABEND routine 

Abnormal Termination Modular Overview 

ABENDO 

ABENDl 

ABEND3 



j Entry Point 

1 Name(s) 

J. _j 


Chart 

L_ 


ID 1 


t ^ — ^ 1 
1 IGC0A05A 


1 .^ 

LI 


1 IGC0L05A 


LI 




IIGC0C05A 


LI 




IIGC0105A 


LI 




IIGC0205A 


LI 




IIGC0305A 


LI 




IIGC0405A 


LI 




IIGC0505A 


LI 




IIGC0605A 


LI 




IIGC0705A 


LI 




IIGC0805A 


LI 




1 IGC0A05A 


LI 




IIGC0B05A 


LI 




1 IGCO J05A 


LI 




1 IGC0K05A 


LI 




1 IGC0M05A 


LI 




IIGC0N05A 


LI 




IIGC0P05A 


LI 




1 IGC0Q05A 


LI 




1 IGCO DOS A 


LJ 




1 IGC0E05A 


LJ 




1 IGC0F05A 


LJ 




1 IGC0G05A 


LJ 




1 IGC0H05A 


None 




1 IGCO 105 A 


None 




IIGC0005A 


ME 




ilGCOZOSA 


MF 
LK 




1 IGCOOOIC 


LL 




1 IGCOIOIC 


LM 




1 IGC0301C 


LN 
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Name of Routine, Control Block, Table, Transient Area 
ABEND4 
ABENDS 
ABEND7 
ABENDS 
ABEND9 
ABENDll 
ABEND12 
ABEND13 
ABEND15 
ABEND16 
ABEND20 
ABTERM routine 

ABTERM Prologue routine 

ABTERM Setsubs subroutine 

Alternate Multiply Control module 
for System/360 Model 85 

Alternate Path Retry 

APR VARY PATH Command Processor 

ATTACH routine 
Attention routine 
BLDL routine 
Buffer Control module 
CDEXIT routine 

Channel-Check Handler Central routine 
Channel-Check Handler 155 Analysis routine 
Channel-Check Handler 2860 Analysis routine 
Channel-Check Handler 145 Analysis routine 
Channel-Check Handler 2870 Analysis routine 
Channel-Check Handler 2880 Analysis Routine 
CHAP routine 



j Entry Point 
1 Name(s) 


Chart 


ID 1 


|IGC0i»01C 


LO 


j 


IIGC0501C 


LP 




IIGC0701C 


LQ 




IIGC0801C 


LR 




IIGC0901C 


LS 




1 IGCOBOIC 


LT 




IIGCOCOIC 


LO 




IIGCODOIC 


LV 




1 IGCOFOIC 


LW 




IIGCOGOIC 


LX 




1 IGCOKOIC 


LY 




IIEAOABOO 
1 lEAOABOl 


LF 
LF 




1 lEAOPLOO 


LH 




1 SETSDBS 


LG 




1 IGFASR6F 
1 IGFMCH18 


None 
None 




IIGF2403D 
IIGF24MPD MP 
1 IGF34MPD 


None 




IIGC042 


BA 




1 lEEBAl 


FA 




1 lECPBLDL 


None 




1 IGFMCH16 


None 




1 CDDESTRY 
1 CDEXIT 
1 CDHKEEP 


KE 
KE 
KE 




1 IGFCAT 


None 




IIGFCCH48 


None 




1 IGFCCH60 


None 




1 IGFCCH68 


None 




IIGFCCH70 


None 




IIGFCCH80 


None 




IIGC044 
IIGC04U+12 


BB,BC 
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r _ _ _ _ _ _ _ — , 

1 Name of Routine, Control Block, Table, Transient Area 


J, , 

Entry Point 
Name(s) 


Chart 


ID 


1 Checkpoint routines 

1 Checkpoint Housekeeping 1 routine 


IGC0006C 


JA 




1 Checkpoint Housekeeping 2 routine 


IGC0106C 


JB 




1 Checkpoint Housekeeping 3 routine 


IGC0206C 


JC 




1 Check I/O routine 


IGC0506C 


JD 




1 Preserve 1 routine 


IGC0A06C 


JE 




1 Preserve 2 routine 


IGC0D06C 


JE 




1 Checkmain 1 


routine 


IGC0F06C 


JF 




1 Checkmain 2 


routine 


IGC0G06C 


JF 




1 Checkmain 3 


routine 


IGC0H06C 


JG 




1 

1 Resume I/O routine 


IGC0N06C 


JH 




1 Checkpoint Exit routine 


IGC0Q06C 


JH 




1 Checkpoint Message Module 
1 


IGC0S06C 


JI 




i Coimmini cations 


Task Attention Interruption Handler 


lEEBAl 


FA 




1 Communications 
1 Load 1 


Task Console Switch routine (MCS) 


IGCXL07B 


FJ 




1 Load 2 




IGCXM07B 


FK 




1 Load 3 




IGCXN07B 


FK 




1 Load 4 




IGCXO07B 


FL 




1 Communications 


Task Device Interface routine (MCS) 


lEECMDSV 


FM 




1 Commvinications 


Task DOM Service routine (MCS) 


lEECMDOM 


FO 




1 Communications 


Task External Interruption Handler routine 


lEEBClPE 


FA 




1 Communications 


Task External Processor routine (non-MCS) 


IGCXL07B 


FH 




1 Communications 


Task Initialization routine 


lEECVCTI 


FD 




1 Communications 


Task Mini-Router 


IGC0007B 


(Fig. 


7-3) 


1 Communications 


Task Misc. Lookup Services routine 


lEEVRFRX 


None 




j Communications 


Task NIP Message Buffer Writer 


IGC0907B 


FP 




1 Communications 


Task Reply Processor routine 


IEE1203D 


None 




1 Communications 


Task MCS Reply Processor routine 


IEE1A03D 


None 




1 Communications 


Task Error Message routine 


IEE1B03D 


None 




1 Communications 


Task Request Block (RB) 


lEECVPRB 


None 




1 Communications 
L 


Task Router routine (non-MCS) 


IGC0007B 


FG 


__ 
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h 



Name of Routine, Control Block, Table, Transient Area 

FI 



Communications Task Router routine (MCS) 

Communications Task TCB 

Communications Task Unit Control Tables 

Communications Task Wait routine (non-MCS) 

Communications Task WTO Handler 

Communications Task WTOR Handler 

Communications Task WTO(R) Service routine (MCS) 

Communications Task 1052 Console Open/Close routine 

Communications Task 1052 Console Processor 1 routine (non-MCS) 

Communications Task 1052 Console Processor 1 routine (MCS) 

Communications Task 1052 Console Processor 2 routine (MCS) 

communications Task 1052/Printer Processor 2 routine (non-MCS) 

Communications Task Printer Open/Close routine 

Communications Task Printer Processor routine 

Communications Task Card Reader Open/Close routine 

Communications Task Card Reader Processor routine 

Communications Task 2740 Console Processor 

Communications Vector Table (CVT) 

Console/SYSRES Clear Channel routine 

Contents Supervision Common Subroutines 
entry points for search phase 

entry point for scheduling phase 

entry point for the ATTACH macro instruction 
entry point for the LINK macro instruction 
entry point for the XCTL macro instruction 
entry point for the LOAD macro instruction 
entry point for the SYNCH macro instruction 
CPU Analysis module 



Entry Point 
Name(s) 



lEECVCTW 
lEECVTCB 
lEECVOCM 
IEECIRI»5 
IGC0003E 
IGC0103E 
lEECMWSV 
IGC0I07B 
IGC0107B 
IGC0107B 
IGC0207B 
1GC0207B 
IGC2I07B 

IGC2107B 

IGC1I07B 

IGC1107B 

IEEC2740 

lEACVT 

IGFNOOOl 

CDADVANS 
CDCONTRL 
also called 
IEAQCS02 

CDEPILOG 
also called 
IEAQCS03 

lEAQCSOl 

IGC006 

IGC007 

IGC008 

IGC012 

IGFASROB 



Chart ID 



None 

None 

FF 

FB 

FC 

FN 

FT 

FQ 

FR 

FS 

(Fig. 7-1) 

(Fig. 7-1, 
7-2) 

(Fig. 7-1, 
7-2) 

(Fig. 7-2) 

FU, FV 

FW 

None 

None 



CA 
CA 



CA 

CA 
CA 
CA 
CA 
CA 
None 
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Name of Routine, Control Block, Table, Transient Area 



Damage Assessment Routine (DAR) 1 

Damage Assessment Routine (DAR) 2 

Damage Assessment Routine (DAR) 3 

Damage Assessment Routine (DAR) 4 

Data control block (DCB) for the SYSl.LINKLIB data set 

Data control block (DCB) for the SYSl.SVCLIB data set 

Data extent block (DEB) for the SYSl.LINKLIB data set 

Data extent block (DEB) for the SYSl.SVCLIB data set 

Decimal Simulator routines for Models 91 and 195 
Add/Subtract/Zero-and-Add Decimal routine 

Analyzer/End routine 

Compare Decimal routine 

Divide Decimal routine 

Multiply Decimal routine 

Simulator Control routine 

Delete routine 

Dequeue routine 

Dequeue TCB routine 

Detach routine 

Dispatcher 

Dynamic Device Reconfiguration 
DDR Central 

DDR SVC Router, Initiator, Terminator 

DDR Operator-Initiated 

DDR System-Initiated (Load 1) 

DDR System-Initiated (Load 2) 

DDR Tape Reposition (Load 1) 

DDRMSG M0D#1 

DDR Tape Reposition (Load 2) 

DDR Recording 

DDRMSG MOD#2 

DDR Resident Module 



Entry Point 

Name(s) j Chart ID 

MA 



IGCOLOIC 

IGCOMOIC 

IGCONOIC 

IGCOPOIC 

LINK DCB 

SVCDCB 

LINKDEB 

SVCDEB 

DECASP 

DBCDO 
OECNEND 

DECCP 

DECDP 

DECMP 

DECENT 

IGC009 

IGC0U8 

lEADQTCB 

IGC062 

lEAODS 

IGE0660A 
IGC0008E 
IGC0108E 
IGC0208E 
IGC0308E 
IGCOtOSE 
IGC0508E 
IGC0608E 
IGC0708E 
IGC0808E 
IGFDDROl 



MB 

MC 

MD 

None 

None 

None 

None 

MI 
ML 

MH 
MK 
MJ 
MG 
CC 
BJ 
LC 
BE 
KF-KL 

None 
None 
None 
None 
None 
None 
None 
None 
None 
None 
I None 
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Name of Routine, Control Block, Table, 



DDR Channel £nd Appendage 
DDR Abnormal End Appendage 
DDR SYSRES Routine 
DDR SYSRES Routine 
DDR SWAP Command Processor 
Device Independent Display Operator 
Console Support (DIDOCS) routines 
Asynchronous Error routine 
Cleanup routine 
Command routine 
Delete 1 routine 
Delete 2 routine 
Delete 3 routine 
Delete U routine 
Display 1 routine 
Display 2 routine 
Display 3 routine 
Light Pen/Cursor Service routine 
Message 1 routine 
Message 2 routine 
Message 3 routine 

Multiple-Line WTO (Non-MCS) Load 1 
Multiple-Line WTO (Non-MCS) Load 2 
Multiple-Line WTO (MCS) Load 1 
Multiple-Line WTO (Non-MCS) Load 3 
Multiple-Line WTO (MCS) load 2 
Multiple-Line WTO (MCS) Load 3 
Multiple-Line WTO (MCS) Load 4 
Model 85 I/O routine 
Open/Close routine 



1 Entry Point 

ble. Transient Area | Name(s) 

1 


Chart ID 1 




IIGFDDR02 


None 1 




1IGFDDR03 


None 1 




IIGFDDR05 


None 1 




1 IGFDDRSR 


None j 




IIGF2503D 


None 1 




1 lEECVETC 


HK 1 




1 lEECVFTG 


^^ 1 




1 IEECVET4 


HS 1 




1 IEECVET6 


lA 1 




1 IEECVET7 


IB 1 




1 IEECVET8 


IC 1 




1 IEECVET9 


ID 1 




1 IEECVET2 


HO 1 




1 IEECVET3 


HP 1 




1 IEECVFT2 


HQ 1 




1 lEECVETF 


IE 1 




1 lEECVETD 


HL 1 




1 lEECVETE 


HM 1 




1 lEECVFTD 


HN 1 




1 lEECVMLl 


GD 1 




1 IEECVML2 


GE 1 




1 IEECVML3 


GD 1 




1 lEECVMLU 


GF 1 




1 IEECVML5 


IGE 1 




1 IEECVML6 


IGF 1 




1 IEECVML7 


GG 1 




1 lEECVETH 


HJ 1 




1 lEECVETG 


|HE 1 
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Name of Rou-tlne, Control Block, Table, Transient Area 



Options routine 

PFK routine 1 

PFK routine 2 

Processor 0, Load 1 

Processor 0, Load 2 

Processor 1, Load 1 

Processor 1, Load 2 

Roll Mode routine 

Status Display Interface 1 

Status Display Interface 2 

Status Display Interface 3 

Status Display Interface 4 

Status Display Interface 5 

Status Display Interface 6 

Status Display Interface 7 

Timer Interpreter routine 

2250 I/O-l routine 

2250 1/0-2 routine 

2260 I/O-l routine 

2260 1/0-2 routine 

End-of-Task (EOT) routine 

Enqueue routine 

ENQ/DEQ Purge routine 

Erase Phase routine 

Error Check Circuitry Verification module 

Error Recorder module for System/370 
for System/360 Model 85 

ESR Extended SVC Router 

Type 1 Router 

Type 2 Router 

Type 3 and 4 Routers 



Entry Point 
Name(s) 



lEECVETA 

lEECVFTA 

lEECVFTB 

lEECVFTl 

lEECVFTZ 

lEECVETl 

lEECVETZ 

lEECVETJ 

lEECVFTL 

lEECVFTM 

lEECVFTN 

lEECVFTO 

lEECVFTP 

lEECVFTQ 

lEECVFTT 

lEECVETK 

lEECVETP 

lEECVETQ 

lEECVETR 

lEECVFTR 

EOT 

IGC056 

lEAQEQOl 

lEAQERA 

IGFASRID 

IGFMCHE2 
IGFMCH17 

IGC116 
IGC117 
IGC109 



Chart ID 



HT 

IG 

IB 

BA 

BB 

BC 

BD 

BR 

IJ 

IK 

IL 

IM 

IN 

10 

IP 

IF 

BF 

BG 

BB 

BI 

LA 

BI 

None 

None 

None 

None 
None 



AC 

AC 

AC 
J. 
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h 



Name of Rout.ine, Control Block, Table, Transient Area 



T " T 

Entry Point 
NaiDe(s) 



EXCP Counter routine 

EXCP Supervisor 

Exit routine 

External First-Level Interruption Handler 

Extract routine 

branch entry point 
First CPU Signal routine 
FREEMAIN routine 

branch entry point 

branch entry point to free a region 

entry point for S-form FREEMAIN macro instruction 
GETMAIN routine 

branch entry point to allocate a region 

branch entry point 

entry point for S-form GETMAIN macro instruction 
GETMAIN/FREEMAIN routines 

entry point for R-form GETMAIN or FREEMAIN macro instruction 

branch entry point 
GETPART/FREEPART routine 
Graphic Console Initialization routine 
HALT and WRITELOG CLOSE routine 
Identify routine 

Initial Program Loading (IPL) routine 
Instruction Retry Analysis module. Phase 1 
Instruction Retry Analysis module. Phase 2 
Instruction Retry Execution module. Phase 1 
Instruction Retry Execution module. Phase 2 
I/O Block (lOB) for the I/O supervisor Transient Area 
I/O First-Level Interruption Handler 
I/O Interruption Supervisor 
I/O Supervisor Transient Area 
I/O Switch (in I/O FLIH) 






lEASMFEX 

lECXCP 

IGC003 

lEAQEXOO 

IGC040 

IGC040+8 

FLASH 

FMBRANCH 
FREEPART 
IGC005 

GETPART 

GMBRANCH 

IGCOOa 

IGCOIO 

RMBRANCH 

lEAQPR 

lEECVGCI 

IEE1403D 

IGCCJl 

START 

IGFASROC 

IGFASRIC 

IGFASR2C 

IGFASR3C 

lEAERRTA 

lEAQIOOO 

lECINT 

lEAERWA 

lORGSW 



Chart ID 



MM 

None 

KB 

AH.AI 

BD 

BD 

None 

DA 
DA 
DA 

DA 
DA 
DA 

DA 

DA 

DB 

FE 

(Fig. 7-10) 

CB 

None 

None 

None 



None 

None 

AJ 

None 

None 

None 



j.- 
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Name of Routine, Control Block, Table, Transient Area 



Job File Control Blocks CJFCBs) for the log data sets 

Link Pack Area Queue 

Log and WRITELOG Post routine 

Log Writer 

Log (Write-to-Log SVC 36) 
Load 1 

Load 2 - Log Data Set Open/Close 

Machine Status Control Module for 
Systein/360 Model 85 (Part 1) 

Systein/360 Model 85 (Part 2) 

System/370 Model 145 

System/370 Model 155 

System/370 Model 165 
Main Storage Analysis Module for 

System/360 Model 85 

System/370 Model 155 

System/370 Model 165 
Main Storage Scan module 
Master Scheduler Initialization routine 
Master Scheduler Resident Table 
Master Scheduler TCB 
MCH Console Write routine 
MCH Emergency Error Recorder module 
MCH Error Recorder module for 

System/360 Model 65 

System/360 Model 85 

System/370 
MCH Initialization module 
MCH Nucleus 

MCH Resident Nucleus module 
MCH Termination routine 
Nucleus Initialization Program (NIP) 



1 Entry Point 
1 Name(s) 
i , ., 


Chart 
(Fig.7- 


ID 1 
-- H 

-10) 1 


(lEEVLOGJ 


1 lEAQLPAQ 


None 




IIEE1603D 


(Fig.7- 


■10) 1 


1 lEELWAIT 


GA 




IIEE0303F 


GB 




IIEE0403F 


GC 




IIGF08501 


None 




IIGF08502 


None 




IIGF29701 


None 




IIGF29601 


None 




IIGF55301 


None 




1 IGFMCH19 


None 




1 IGFMCH21 


None 




1 IGFMCH33 


None 




IIGFASR2D 


None 




1 lEEVIPL 


(Fig.7- 


-10) 1 


jIEEMSER 


None 




1 lEAMSTCB 


None 




1 IGFMCHEl 


None 




1 IGFMCHE3 


None 




(IGFASROl 


None 




1 IGFMCH17 


None 




1 IGFMCHE2 


None 




1 IGFMCHFO 


None 




1 IGFMCHEO 


None 




1 IGFNOOOO 


None 




IIGFN0002 


None 




1 IEANIP4 


None 
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Name of Routine, Control Block, Table, Transient Area 



Overlay Supervisor 

nonresident module 

resident module 

entry point for SEGLD or SEGWT macro instruction 

entry point for a branch instruction or CALL macro 
instruction 

PDAR Termination Analysis module for 

System/360 Model 65 

System/360 Model 85 

System/370 
Post routine 

brcuich entry point for I/O Supervisor routines 

branch entry point for I/O Supervisor routines and 
for supervisor routines 

entry point for the POST macro instruction 

branch entry point for supervisor routines 

Preliminary Error Analysis module for 
System/360 Model 85 
System/370 Model 145 
System/370 Model 165 

Program Check First^Level Interruption Handler 

Program Fetch routine 

entry point for the Overlay Supervisor (lEWSZOVR) 

entry point for the Transient Area Fetch routine 

entry point for Contents Supervision common subroutines 

Program Fetch Channel^End Appendage routine 

Program Fetch PCI Appendage routine 

Purge Timer routine 

QCB queues, origin of 

Refresh Clear Channel module 

for System/366, Model 65 and Model 65 Multiprocessor 



Entry Point 
Name(s) 



— r- 



lEWSZOVR 



IGC037 



iGcoas 



IGFASR20 


None 


IGFMCHF5 


None 


IGFMCHF5 


None 


lEAOPTOl 


BH 


IEAOPT02 


BH 


IGC002 


BH 


IGC002+6 


BH 


IGFMCH13 


None 


IGFMCH41 


None 


IGFMCH31 


None 


lEAQPKOO 


AF.AG 


lEWFBOSV 


CD 


lEWFTRAN 


CD 


lEWMSEPT 


CD 


FTCEOl 


CD 


FTPCIOl 


CD 


lEAQPGTM 


LD 


lEAQQCBO 


None 



IGFASRIA 



Chart ID 



CE 



CE 



CE 



None 
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Name of Routine, Control Block, Table, Transient Area 
Refresh Loader module 

for System/360, Model 65 and Model 65 Multiprocessor 

for System/360, Model 85 
Refresh/Repair Verification module for 

System/360 Model 85 

System/370 Model 155 

System/370 Model 165 (Part 1) 

System/370 Model 165 (Part 2) 
Reply Purge routine (also called the WTOR Purge routine) 
Release Loaded Programs routine 
Release Main Storage routine 
Restart Routines 

DOS Tape Data Set Processor 

ISAM and BDAM Data Set Processor 

Restart Job Management-SMB Reader 

Restart Housekeeping 1 

Restart Housekeeping 2 

Repmain 1 routine 

Repmain 2 routine 

Repmain 3 routine 

Repmain 4 routine 

Repmain 5 routine 

REP I/G-JFCB Processor 1 

REP I/O-JFCB Processor lA 

REP I/O-JFCB Processor 2 

REP I/O-Dummy Data Set Processor 

REP TCAM Data Set Processor 

REP I/O-Mount/Verify 1 (Non Direct Access) routine 

REP I/O-Mount/Verify 2 (Direct Access) routine 

REP I/O-SYSIN/SYSOUT Data Set Processor 1 

REP I/O-SYSIN/SYSODT Data Set Processor 2 



T -T 

Entry Point 
Name(s) 



Chart ID 
+— 



IGFASRIO 
IGFMCHFt 

IGFMCH14 

IGFMCH23 

IGFMCH35 

IGFMCH36 

lEECVPRG 

lEAQABL 

lEAQSPET 

IGCOD05B 
IGC0W05B 
IGC0005B 
IGC0105B 
IGC0205B 
IGC0505B 
IGC0605B 
IGC0705B 
IGC0805B 
IGC0905B 
IGC0G05B 
IGC0G95B 
IGC0I05B 
IGC0H05B 
IGC0J05B 
IGC0K05B 
IGC0M05B 
IGC0N05B 
IGC0Q05B 



None 
None 

None 

None 

None 

None 

None 

LE 

LE 

JY 

None 

None 

JJ 

JJ 

JK 

JL 

JM 

JN 

JN 

JO 

JO 

JO 

JP 

JX 

JQ 

JR 

JS 

JS 
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I 



Name of Routine, Control Block, Table, Transient Area 



REP I/O-Data Set Processor 1 

REP I/O-Data Set Processor lA 

REP I/O-Data Set Processor 2 

REP I/O-Access Method-Disposition routine 

Restart Exit routine 

SYSIN/SYSODT Non-DASD Data Set Processor 

Rollout/Rollin module 

Second CPO Interruption Analysis routine 

Second CPO Recovery Management System Interface routine 

Secondary Communications Vector Table 

SEGLD Processor routine 

SERO routine 

resident module 

nonresident modules (for System/360 Models 40, 50, 65, 75) 

SERl routine (for System/360 Models HO, 50, 65, 75) 
(for System/360 Models 91, 95, 195) 

STATUS Service routine 

SMF EXCP Counter routine 

SMF Storage routines 

SMF Wait Time Collection routine 

SMF Time/Output Limit Expiration routine 

Soft Machine-Check Handler for 

System/370 Model 145 

System/370 Model 155 

System/370 Model 165 
SPIE routine 
STAE Service routine 

ABEND/STAE Interface routine 

ABEND/ STAE Interface 1 routine 

ABEND/STAE Interface 2 routine 

ABEND/STAE Interface 3 routine 






Entry Point 
Name(s) 



IGC0P05B 

IGC0S05B 

IGC0R05B 

IGC0T05B 

IGC0V05B 

IGC0L05B 

lEAQRORI 

INTEXTRN 

INTMLFAL 

lEABEND 

OVLALD02 

lEAMCHOO 

IFBSEROO 
SECMCI 

lEAMCHOO 
lEAMCHOO 

IGC079 

lEASMFEX 

FMSMFCRE 
GMSMFCRE 

lEAQWAIT 

lEATLEXT 

IGFMCH40 

IGFMCH20 

IGFMCH30 

IGC014 

IGC00060 

IGCOROIC 

IGCOSOIC 

IGCOTOIC 

IGCOUOIC 



Chart ID 



JT 

JU 

JV 

JW 

JW 

None 

DC-DI 

None 

None 

None 

CE 

AK 

AK 
AK 

AL 
AM 

BW 

MM 

DA 
DA 

MO 

MN 

None 

None 

None 

BF 

BP 

BQ 

BR 

BS 

BT 
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Neiine of Routine, Control Block, Table, Transient Area 



T™ . y 

Entry Point 
Naine(s) 



ABEND/STAE Interface U routine 

ABEND/STAE Interface 5 routine 

Stage 1 Exit Effector 

Stage 2 Exit Effector 

Stage 3 Exit Effector 

entry points for the Dispatcher 

entry point for an I/O error-handling routine 

STIMER routine 

Storage Protection Feature Analysis module for 
Systein/360 Model 85 

Systein/370 Model 155 

Systein/370 Model 165 

Storage Protect Feature Test Module 

Subsystem Interface Module for System/370 Model 165 

Subsystem Purge routine 

SVC First^Level Interruption Handler 

SVC Purge routine 

SVC Second-Level Interruption Handler 

SVC Table 

start of IBM-assigned SVC numbers 

start of user-assigned SVC numbers 

SWAP Command Processor 

System Analysis module 

for System/360, Model 65 and Model 65 Multiprocessor 

System/360 Model 85 and System/370 

Part 1 

Part 2 

Part 3 

System error TCB (associated with I/O Supervisor transient 
areas) 

Task Removal routine 

Task Switching routine 

Terminal Attention Exit Element Purge routine 



IGCOVOIC 
IGCOWOIC 
IGC0t3 
lEAOEFOO 

ERFETCH 
IEA0EF03 

lECXTLER 

IGC047 

IGFMCH15 

IGFMCH22 

IGFMCH34 

IGFASROD 

IGFMCHF6 

lEAASPRG 

lEAQSCOO 

IGC016 

lEAQTROO 

IBMORG 

USERORG 

IGF2503D 

IGFASROO 

IGFMVTFl 
IGFMVTF2 
IGFMVTF3 

lEAERTCB 
TESTDSP 
IEA0DS02 
lEAKJXP 



Chart ID 



BO 
BV 
BK 
BL 

BM 
BM 

BM 

EB,EF 

None 

None 

None 

None 

None 

None 

AA 

None 

AB 

None 
None 
None 

None 

None 
None 
None 

None 
None 
BN,BO 
LB 
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T— --T 

Entry Point 
Naine(s) 
+ 



Name of Routine, Control Block, Table, Transient Area 



1 _ ._-+ 

TESTRAN Interpreter 

entry point for SVC 61 instruction 

entry point for the Overlay Supervisor (lEWSZOVR) 
Time routine 
Timer Second-Level Interruption Handler 

branch entry point 

entry point for the Dispatcher 

branch entry point 

entry point for the External First-Level 
Interruption Handler 

Trace routine 

entry point for the Dispatcher 

entry point for the Externeil First-' Level 
Interruption Handler 

entry point for the I/O First-Level Interruption Handler 

entry point for the Program Check First-Level 
Interruption Handler 

entry point for the SVC First-Level Interruption Handler 

Transient Area Availability Check routine 

Transient Area Control Table 

Transient Area Exit routine 

entry point for the Exit routine 

entry point for the common subroutines of Contents Supvsn. 
Transient Area Fetch routine 

entry point to perform BLDL and fetch 

entry point to perform fetch only 
Transient Area Fetch TCBs 



Transient Area I/O Blocks (lOBs) and associated transient areas 
Transient Area Refresh routine 



IGC061 

lEGHTOVL 

IGCOll 

lEAQTDOO 
lEAQTDOl 
lEAQTEOO 

lEAOTIOO 
TRDISP 



TREX 


None 


TRIO 


None 


TRPI 


None 


TRSVC 


None 


TATABCK 


AD 


lEAQTAQ 
lEAQTAQl 


None 
None 


lEAQTROl 


KC 


TAXEXIT 


KC 


TABLDL 


AE 


TAHFETCH 


AE 


lEATCBl 
IEATCB2 
lEATCBn 
IEATCBn+1 


None 
None 
None 
None 


TAIOBl 
TAI0B2 


None 
None 


IEAQTR02 


KD 



Chart ID 



None 
None 
EA.EE 

ED, EH 
ED, EH 
ED, EH 

ED, EH 
None 
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Ncune of Routine, control Block, Table, Transient Area 
Transient Area XCTL routine 



TTIMER routine 

Type-1 SVC Exit routine 

Type-1 SVC Switch (in SVC First^Level Interruption Handler) 

Validity Check routine 

VARY PATH Command Processor 

Wait routine 
Write- to- Log routine 
Write-to-Operator routine (MCS) 
Write-to-Operator routine (Non-MCS) 
Write-to-Programmer routine 

Initiali zation 

Processing 

Error 
WRITELOG Available Log Data Set routine 
WRITELOG Dispatch routine 
WRITELOG Get Region routine 
WRITELOG Log Initialization routine 
WRITELOG Log Writer routine 
WRITELOG Master Wait routine 
WRITELOG Open Device routine 
WTOR Purge routine (also called the Reply Purge routine) 





— r ■ — ■ — - - ■! I 




1 Entry Point 




ransient Area 


1 Name(s) 


Chart ID 1 






1 




1 IEAQTR03 


CA j 




1 TASEARCH 


CA j 




ITAXRETRY 


CA 1 




IIGC046 


EC, EG 1 




1 lEAOXEOO 


KA 1 


ption Handler) 


1 lEATYPEl 


None I 




1 lEAOVLOO 


None 1 




|IGF2l|03D 


None 1 




1 IGF21tMPD MP 






1 IGF34MPD 






IIGCOOI 


BG 1 




IIEE0303F 


GB 1 




1 IGC0003E 


FB 1 




1 IGC0003E 


FB 1 




IIGC0203E 


None 1 




IIGC0303E 


None 1 




1 IGC0403E 


None 1 




1 lEEVLOOT 


(Fig. 7-10) 1 




1 lEEVLDSP 


(Fig. 7-10) 1 




1 lEEPLDSP 


None I 




1 lEEVLIN 


(Fig. 7-10) 1 




(lEEVLWTR 


(Fig. 7-10) 1 




1 lEEVWAIT 


(Fig. 7-10) 1 




1 lEEVLOPN 


(Fig. 7-10) 1 


•ge routine) 


1 

1 lEECVPRG 


None 1 






Figure 14-2. Directory of Entry Point Names and Flowchart Identifications (Part 15 of 15) 



Section l«t: Program Organization 747 






SVC 
Instruction 



SVC 

SVC 1 
SVC 2 
SVC 3 
SVC H 
SVC 5 
SVC 6 

SVC 7 

SVC 8 



SVC 


9 


SVC 


10 


SVC 


11 


SVC 


12 


SVC 


13 


SVC 


14 


SVC 


15 


SVC 


16 


SVC 


18 


SVC 


19 


SVC 


20 


SVC 


34 


SVC 


35 


SVC 


36 


SVC 


37 



Name of Routine 



EXCP Supervisor (in the I/O 
Supervisor) 

Wait routine 

Post routine 

Exit Routine 

GETMAIN routine 

FREEMAIN routine 

Contents Supervision common 
subroutines (entry point for 
the LINK macro instruction) 

Contents Supervision common 
subroutines (entry point for 
the XCTL macro instruction) 

Contents Supervision common 
subroutines (entry point for 
the LOAD macro instruction) 

Delete routine 

GETMAIN/FREEMAIN routines 

Time routine 

Contents Supervision common 
subroutines (entry point for 
the SYNCH macro instruction) 

ABEND routine (ABENDO) 

SPIE routine 

ERREXCP (reinstate system 
error task) 

SVC Purge routine 

BLDL routine 

Open routine 

Close routine 

Log and WRITELOG Post routine 

Writ e-to- Operator routine 

Write-to-Log routine 

Overlay Supervisor resident 
module (entry point for SEGLD 
or SEGWT macro instructions) 



Figure 14-3. Table of Routines Invoked by 
SVC Instructions (Part 1 of 2) 



r- — 1 

1 SVC 

1 Instruction 


Name of Routine 


1 SVC 40 


Extract routine 


1 SVC 41 


Identify routine 


1 SVC 42 


Attach routine 


1 SVC 43 


Stage 1 Exit Effector 


1 SVC 44 


CHAP routine 


1 SVC 45 


Overlay Supervisor resident 
module (entry point for 
branch instruction or CALL 
macro instruction) 


1 SVC 46 


TTIMER routine 


1 SVC 47 


STIMER routine 


1 SVC 48 


DEQ routine 


1 SVC 51 


ABDUMP routine (ABDUMPl) 


1 SVC 52 


Restart routine 


1 SVC 56 


ENQ routine 


1 SVC 60 


STAE Service routine 


1 SVC 61 


TESTRAN Interpreter (entry 
point for TTSAV macro 
instruction) 


1 SVC 62 


Detach routine 


1 SVC 63 


Checkpoint routine 


1 SVC 72 


Communications Task Router 
routine 


1 SVC 79 


Set status routine 


1 SVC 85 


Dynamic Device Reconfigura- 
tion routine 


1 SVC 87 


Delete Operator Message 
routine 


1 SVC 109 


Type 3 and Type 4 Extended 
SVC Router routine 


1 SVC 116 


Type 1 Extended SVC Router 
routine 


1 SVC 117 

L- _ _ J 


Type 2 Extended SVC Router | 
routine j 

L_ J 


r 

iNote: Only 


1 
those routines that are used | 


|by the supei 
jlist. 


rvisor are included in this j 

1 



Figure 14-3. Table of Routines Invoked by 

SVC Instructions (Part 2 of 2) 
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ROUTINE SYNOPSES 

Each major routine used by the supervi- 
sor is briefly described. 



ABDDMP routine ; (Chart LI) Displays con- 
trol blocks, programs, and dynamically 
acquired main storage belonging to a spe- 
cific task, as specified by input parame- 
ters. Is invoked through a SNAP macro 
instruction either by the ABEND routine 
during an abnormal termination, or by a 
user routine at any time. 



ABEND routine ; (Charts LK-LY) Invokes the 
ABEND/STAE interface routine if STAE pro- 
cessing is indicated. Transfers control to 
the Damage Assessment Routine (DAR) routine 
if any of three conditions occurs; the 
task specified for termination is in "must 
complete" status, the task specified for 
termination is a system task, or the ABEND 
routine is reentered as an invalid recur- 
sion. Depending on the type of ABEND requ- 
est, terminates either a specific task and 
its incomplete subtasks, or all tasks of a 
job step. Issues WTP messages for type-1 
SVC routines when possible. At the cal- 
ler's option (if possible), invokes the 
ABDDMP routine to display resources belong- 
ing to the terminating task, its direct 
ancestors, and its descendants. Frees the 
control blocks, main storage, and other 
resources used by a terminating task and 
its incomplete subtasks. 

ABTERM routine ; (Charts LF, LG) Schedules 
execution of the ABEND routine. Is used by 
system routines that wish to terminate a 
task other than their own. Also used by 
type-1 SVC routines, which are not per- 
mitted to issue an SVC instruction, and 
vrtiich therefore cannot directly invoke the 
ABEND routine. 

ABTERM Prologue routine ; (Chart LH) Per- 
forms housekeeping functions in preparation 
for entry to the ABTEEIM routine after a 
program interruption. Housekeeping 
includes obtaining the address of the TCB 
for the task to be terminated, and setting 
a completion code to indicate the cause of 
the program check. 

Alternate Path Retry (APR) ; Not model- 
dependent. Allows an I/O operation that 
has developed an error on one channel to be 
retried on another channel (if another 
channel is assigned to the device perform- 
ing the I/O operation) by causing channel- 
detected errors to be retried in a selec- 
tive manner on the available paths to a 
device. As paths are found to be inopera- 
tive, they are marked offline, thus pre- 
venting unnecessary retry from being 
initiated to failing paths. 



Also provides the capability to VARY a 
path to a device online or offline, using 
the VARY PATH command. VARY PATH command 
processor is part of the Master Scheduler 
(SVC 34). Last path to a device will not 
be varied offline. Four paths to each 
device supported; teleprocessing paths not 
supported. 

(For a full description of Alternate 
Path Retry, refer to the Input/Output 
Supervisor PLM . 



Attach routine ; (Chart BA) Obtains storage 
space for a new TCB for the subtask to be 
attached. Places in the new TCB informa- 
tion needed to control the subtask. Allo- 
cates to the subtask subpools of main 
storage belonging to its parent or attach- 
ing task. Places the address of the new 
TCB on two lists; the subtask queue of its 
parent task, and the TCB queue used by the 
Dispatcher. Schedules supervisor linkage 
to the common subroutines of Contents 
Supervision. The subroutines will locate, 
fetch (if necessary) , and schedule execu- 
tion of the first program of the new 
subtask. 



Attention routine ; (Chart FA) Receives 
control from the I/O First-Level Interrup- 
tion Handler after an operator- caused 
interruption (when the REQUEST key of a 
1052 Printer-Keyboard or the START key of a 
card reader is pressed) . Posts the appro- 
priate ECB of the Communications Task. 

BLDL routine ; Causes member addresses and 
optional information from a partitioned 
data set directory to be placed in a speci- 
fied list previously constructed in main 
storage. 

CDEXIT routine ; (Chart KE ) Determines if 
there is an outstanding request for use of 
a recently completed module. If so, sche- 
dules reentry to the module for a waiting 
requester. If there is no outstanding 
request for the module, the routine tests 
the module's attributes. If the module is 
in the link pack area, control is returned 
immediately to the caller. If the module 
is in the job step's region, and is either 
reenterable or reusable, the routine sets 
the "release" flag in the module's CDE and 
the "purge" flag for the job pack queue. 

(These flags are tested by the GETMAIN rou- 
tine to determine which module's space may 
be freed, if needed space is otherwise 
unavailaijle. ) If the module is neither 
serially reusable nor reenterable, CDEXIT 

(via its CDDESTRY subroutine) removes the 
module's CDE from the job pack queue, and 
frees the space occupied by the module, its 
extent list, and its CDEs (major and 
minor) . 
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Channel'-Check Handler (CCH) ; Available on 
configurations using the 2860, 2870, 2880, 
145 or 155 channels (Model 65 and higher) . 
Receives control from the I/O Supervisor 
via a branch when a channel error occurs. 
It performs two major functions. It pro- 
vides an analysis of the channel logout 
information in the error recovery procedure 
interface block (ERPIB) to aid the appro- 
priate device-dependent error recovery pro- 
cedure in setting up for a retry of the 
failing operation by the I/O Supervisor. 
CCH also records environmental data about 
the channel error in a channel error 
inboard record entry. This record entry is 
later written onto the SYSl.LOGREC by the 
outboard recorder routine (OBR) of the I/O 
Supervisor. An operator message is issued 
each time a channel error is recorded. 
(For a full description of the Channel- 
Check Handler, refer to the Input/Output 
Supervisor PLM . 



CHAP routine ; (Charts BB, BC) Changes the 
dispatching priority of a TCB by adding the 
specified value to the TCB's existing dis- 
patching priority. Validates the new dis- 
patching priority and corrects it if 
necessary. 



Checkpoint routines ; (Charts JA-JI) Inter- 
cept a task's I/O requests, copy the task's 
main storage region into a user-supplied 
data set, and record the status of data 
sets, main storage and contents supervision 
control blocks, and other supervisor infor- 
mation necessary to restart the task's 
execution at a later time. 



Communications Task External Interruption 
Handler routine ; (Chart FA) Receives con- 
trol from the External First-Level Inter- 
ruption Handler after an operator- caused 
interruption (when the INTERRUPT key on the 
system control panel is pressed) . Posts 
the appropriate ECB of the Communications 
Task. 

Communications Task External Processor rou- 
tine ; (Chart FH) Switches control from the 
principal console device to the alternate 
console device, and vice versa. 

Communications Task Initialization routine ; 
(Chart FD) Initializes tables used for the 
Communications Task. Is executed when nuc- 
leus initialization is performed. 

Communications Task Miscellaneous Look- Dp 
Services routine ; Provides Communications 
Task routines with the addresses of tables, 
or pointers to information in the tables. 
The tables include the communications vec- 
tor table (CVT), TCBs, RBs, task I/O tables 
(TIOTs), and unit control blocks (UCBs) . 



Communications Task Reply Processor rou- 
tine ; Processes replies given by an opera- 
tor in response to program messages written 
via the WTOR macro instruction. 



Communications Task MCS Reply Processor 
routine ; Processes replies given by the 
operator in an MCS environment in response 
to program messages written via the WTOR 
macro instruction. 

Communications Task Error Message routine ; 
Assembles, edits, and broadcasts accepted 
replies to a WTOR macro instruction for the 
Communications Task MCS Reply Processor 
routine, and writes error messages to the 
operator when replies are in error. 

Communications Task Router routine ; (Chart 
FG) Selects the service to be performed 
after the posting of an ECB for the Com- 
munications Task. Routes control to the 
appropriate Communications Task processor 
routine. 

Communications Task unit control tables ; 
Describe characteristics of the I/O devices 
that perform the Communications Task. Also 
contain ECBs for the Communications Task. 

Communications Task Wait routine ; (Chart 
FF) Waits for an ECB to be posted, then 
issues an SVC- 72 instruction to cause entry 
to the Communications Task Router routine. 

Communications Task Open/Close routines ; 
(Chart FT) Device- dependent routines that 
cause data sets for specific devices to be 
opened and closed. The devices are the 
1052 Console, the 2540 Console, and the 
1443 Printer. 

Communications Task Processor routines ; 
(Charts FQ, FR, FS, FD, FV, FW) Device- 
dependent routines that direct activity on 
specific devices by initiating I/O activi- 
ty, managing data buffers, and responding 
to I/O completion and error conditions. 
The devices are the 1052 Console, the 2540 
Console, and the 1443 Printer. 

Contents Supervision common subroutines ; 
(Chart CA) Locate, fetch, and schedule 
execution of a specified module. If the 
module is in main storage and is available 
for use, schedule its execution. If the 
module is not in main storage, or is non- 
reusable, locate the module. They search 
the specified private library, the link 
library, or the job library; then invoke 
the Program Fetch routine to load the 
module. Finally, they schedule execution 
of the module. If the module is being 
loaded or is serially reusable and is in 
use, they place the current SVRB in a wait 
condition, and queue it to a list of SVRBs 
waiting for the module. 



750 



console Support routines ; Added to SVC 72 
for READ, WRITE, OPED, and CLOSE functions 
for the IBM 1052 Printer-Keyboard, as well 
as OPEN and CLOSE functions for the 2740 
Communications Terminal. These routines 
perform buffer management for the 1052 
Printer-Keyboard only if Multiple Console 
Support (MCS) is included. 



Damacfe Assessment routine (PAR) ; (Charts 
MA-MD) Receives control from various ABEND 
modules. Attempts to write a core image 
dump, reinstates or initiates reinstatement 
of a failing task or region, and informs 
the operator if this is impossible so that 
the operator may halt system processing. 



Decimal Simulator routines ; (Charts MG-ML) 
Perform decimal arithmetic instructions on 
Models 91 and 195. After receiving control 
from the Program First-Level Interruption 
Handler, interpret the instruction, check 
it for validity, and perform operations 
that simulate the execution of the 
in str uction . 



Delete routine ; (Chart CO Locates the CDE 
for the specified module via a search of 
the task's load list. If there are no out- 
standing LOAD requests for the module, 
removes the module's load list element from 
the load list and frees the storage space 
it occupies. Tests the use/responsibility 
count in the module's CDE. If there eire no 
outstanding requests for the module's use, 
branches to CDHKEEP in the CDEXIT routine 
to test the module's attributes. According 
to the attributes, CDHKEEP returns control 
immediately to the caller, or frees the 
module's storage areas, or sets "release" 
and "purge" flags for use by the GETMAIN 
routine (see CDEXIT routine) . 

Dequeue routine ; (Chart BJ) Updates the 
resource queues by removing and freeing the 
queue element that represents the request 
for the resource whose use is now complete. 
For the next requester represented on the 
QEL queue, reduces the wait count in its 
SVRB and tests if the requester is ready. 
Determines if a readied requester can 
replace the caller as the next-to-be dis- 
patched routine. Makes this determination 
via a branch to the Task Switching routine. 
If no readied requester's task is of higher 
priority than the caller's, returns control 
to the caller. Otherwise, returns control 
to the readied requester, whose resource(s) 
are now available. 

If the caller is a system routine and 
specifies the "reset must complete" 
operand, the ctirrent task, previously 
placed in "must complete" status, is 
released from that status. 



Dequeue TCB routine ; (Chart LC) Is invoked 
by either the EOT routine or ABEND16 during 
a normal or abnormal termination. Removes 
a specified TCB from the TCB queue. 

Detach routine ; (Chart BE) Removes the 
specified TCB from the TCB queue, and frees 
the TCB's storage space and the space of 
any associated problem- program register 
save area. If the caller supplies an in- 
valid TCB address, the routine branches to 
the ABTERM routine to schedtile abnormal 
termination of the caller's task. If the 
specified task is incomplete, the routine 
branches to the ABTERM routine to schedule 
abnormal termination of the specified task. 

Dispatcher ; (Charts KF-KL) Determines the 
routine to be executed next, restores the 
contents of saved registers, and loads an 
old PSW to give control to the routine. As 
an optional feature, if a task switch is to 
occur, suspends timing of the previously 
current task, starts or resumes timing of 
the task to be given control, and branches 
to the GTF routines, if active, or the 
Trace routine to record information about 
the task switch. 

Display Operator Console Support routines ; 
(Charts HA-IP) Added to SVC 72 only if Mul- 
tiple Console Support (MCS) is included. 
These routines provide uniform console sup- 
port for the 2250 Display Unit (Models 1 
and 3) , the 2260 Display Station (Model 1 
with 2848 Display Control, Model 3) , and 
the Model 85 CRT Display (Feature 5450) . 

Dynamic Device Reconfiguration (DDR) ; Not 
model-dependent; standard for M65MP. 
Allows a demountable volume to be moved 
from one device to another, and reposi- 
tioned if necessary, without abnormally 
terminating the affected job or reperform- 
ing IPL. A request to move a volume may be 
initiated by the operator with the SWAP 
command; the SWAP command processor is part 
of the Master Scheduler (SVC 34). System 
may request a swap of volumes following a 
permanent I/O error for non-SYSRES devices 
(interface through OBR/SDR) , or following 
an error in a system fetch operation for 
SYSRES devices (interface through TA Fetch 
or error fetch sequence) . (For a full 
description of Dynamic Device Reconfigura- 
tion, refer to the Input/Output Supervisor 
PLM. 

End-of-Task (EOT) routine ; (Chart LA) 
Frees the resources used in performing a 
successfully completed task. The resources 
(control blocks, main storage, data sets, 
modules) are released only if they are not 
needed by another task. 

Enqueue routine ; (Chart BI) Creates, 
if necessary, one or more queue control 
blocks (QCBs) to represent the requested 
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resource (s), and places them on the 
resource queues. Depending on the RET pa- 
rameter that the caller has specified, 
creates a queue element (QEL) to represent 
the request, and places it on a QEL queue. 
If the requested resource is not enqueued 
for another requester, returns control to 
the current requester, with or without a 
return code (depending on the RET parame- 
ter) . If the requested resource is already 
enqueued for another requester, either of 
two functions are performed, depending on 
the RET parameter: the current requester 
is placed in a wait condition, pending the 
availability of the resource; or control is 
returned to the current requester, with a 
return code that indicates that the 
resource is not available. 

If the caller is a system routine and 
specifies the "set must complete" operand, 
the Enqueue routine places the current task 
in "must complete" status. 

ENQ/DEQ Purge routine ; Is invoked by ABEND 
to remove from the resource queues requests 
(QELs and possibly one or more QCBs) 
belonging to a terminating task. The purge 
is performed so that routines belonging to 
other tasks could gain access to the 
enc[ueued resource (s), if the task ter- 
minated before the DEQ routine could be 
executed. 

Erase Phase routine (also called the Erase 
routine) ; Is invoked by the EOT routine or 
ABEND during a normal or abnormal termina- 
tion. Removes the specified TCB frcan its 
parent's subtask queue, and frees the space 
occupied by the TCB and any related 
problem-program register save area. (A 
similar function is performed by the Detach 
routine under different circumstances.) 

EXCP Supervisor ; Is a part of the I/O 
Supervisor. Given control by the SVC 
Fir St- Level Interruption Handler, it starts 
execution of a channel program. It issues 
a Start I/O instruction, then a Stand-Alone 
Seek command. The Stand-Alone Seek command 
moves the access arm of the direct access 
device to the seek address contained in the 
caller's lOB. 

Exit routine ; (Chart KB) Processing 
depends on the type of RB associated with 
the exiting routine, as follows; 

1. If the task's current RB is a PRB (see 
Chart FB) , the general register con- 
tents are moved from lower main 
storage (location lEASCSAV) to the 
TCB. If the PRB is not the last RB on 
the RB queue, the routine branches to 
the CDEXIT routine to perform exit 
processing for the completed module. 
When CDEXIT returns control, function 
#5 is performed (see below). If the 



PRB is the last RB on the RB queue 
(queued directly from the TCB) , the 
EOT routine is entered to normally 
terminate the task. When the EOT rou- 
tine returns control, the Exit routine 
frees the RB's space and exits to the 
Transient Area Refresh routine. 

2. If the task's ciirrent RB is an SVRB 
(see chart FB), the Exit routine 
branches to the Transient Area Exit 
routine to remove ( if necessary) the 
SVRB from a transient area user queue. 
When control is returned, the register 
contents originally saved in the SVRB 
(registers 2-lt) and register contents 
returned by the SVC routine (regs 0, 
1, 15) are in the TCB's save area. 
Function #5 is then performed (see 
below) . 

3. If the task's current RB is an IRB 
(see Charts FB-FC), the "top" IQE or 
RQE on the IRB's list of elements is 
returned to a next- available list. If 
there is another IQE or RQE queued to 
the IRB, the routine reinitializes the 
IRB for reentry to the asynchronous 
exit routine, and branches to the Dis- 
patcher. But if there is no other IQE 
or RQE queued to the IRB, the routine 
moves register contents from the IRB's 
register save area to the TCB's 
register save area. Function #5 is 
then performed (see below). 

U. If the task's current RB is an SIRB, 
it is removed from the system error 
TCB, the SIRB's "active" bit is reset, 
and the Transient Area Refresh routine 
is entered. 

5. If the next RB on the task's RB queue 
is waiting, the routine indicates to 
the Dispatcher the need for a task 
switch by placing zero in the "hew" 
TCB pointer. The routine clears the 
RB's "active" flag and removes the RB 
from the task's RB queue. If the RB 
is not a permanent syston RB nor an 
IRB that is still needed, *^ the RB's 
storage space is freed. Also freed is 
space used for a related problem- 
program register save area. The Exit 
routine then enters the Transient Area 
Refresh routine. 

Extended SVC Router ; (Chart AC) Provide 
linkage to Supervisor Service routines by 
logically extending the routing capability 
of the SVC Interruption Handlers. ESR 
accomplishes this via a secondary routing 



^An IRB may be retained for use with the 
same end-of-task exit routine (ETXR) for 
another task. In this case, its RBUSE 
count is not zero. 
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algorithm based on a parameter established 
prior to issuance of one of the ESR SVCS 
(116, 117, or 109). 

External First-Level Interruption Handler ; 
(Charts AH,AI) Saves the caller's register 
contents in the TCB and the external old 
PSW in the current RB. Branches to the GTF 
routines, if active, or the Trace routine 
to record information about the external 
interruption. Deteinnines whether the 
interruption was caused by the operator or 
the timer, by examining the interruption 
code in the external old PSW. Depending on 
the cause of the interruption, gives con- 
trol to either the Timer Second-Level 
Interruption Handler or the Console Switch 
routine. 

In a Model 65 Multiprocessing System, 
after saving the old PSW, determines if a 
FLIH routine, other than External FLIH, was 
interrupted. If it was, saves the inter- 
ruption code and returns control. Other- 
wise, processes the interruption after set- 
ting the supervisor lock byte. Also, 
determines if the interruption was caused 
by the second CPU, and, if it was, passes 
control to the routine indicated in the 
STMASK byte of the second CPU. 

Extract routine ; (Chart BD) Moves the con- 
tents of selected TCB fields to a specified 
area of main storage. 

FREEMAIN routine ; (Chart DA) Frees speci- 
fied allocated main storage. If request is 
to free a region, the job pack queue is 
purged. In this case tasks that are wait- 
ing for allocation of a region are made 
ready and task switch is indicated. 

In a Model 65 Multiprocessing System, 
branches to the Vary Storage Offline (IFSV- 
RYOF) subroutine to process VQEs which 
apply to the freed area of main storage. 

Generalized Trace Facility (GTF) ; Assists 
in tracing program flow by monitoring and 
recording system events. Initiated by the 
operator issuing the START command; 
executes as a system task. When active, 
the optional Trace Table facility must be 
disabled. 



GETMAIN routine; 



(Chart DA) Allocates main 



storage space and builds main storage con- 
trol blocks, if needed. If the request is 
for system queue area and there is no 
available space in this area, expands the 
supervisor queue area, if possible. If re- 
quest is not for system queue area, and 
free space is not available, makes space 
available by purging those modules in the 
region's job pack area whose CDEs have 
"release" flag set. These modules have no 
outstanding requests for their use and have 
been so flagged by the CDEXIT routine. If 



sufficient module space cannot be made 
available, branches to the ABTERM routine 
to schedule the abnormal termination of the 
caller's task. 

Identify routine : (Chart CB) Creates a 
minor CDE to represent the specified 
embedded entry point to a load module. 
Queues the minor CDE to the module's major 
CDE on the appropriate CDE queue. 

Initial Program Loading (IPL) routine ; 
Clears main storage and machine registers 
to correct parity. Sets the storage pro- 
tection key of main storage to the supervi- 
sor protection key. Locates the nucleus 
data set on the system residence device. 
Loads into main storage the nucleus and the 
Nucleus Initialization Program (NIP) . 
Gives control to the NIP. 

I/O First^Level Interruption Handler ; 
(Chart AJ) Sets the I/O switch (lORGSW) to 
indicate that an I/O interruption has 
occurred. Saves current register contents 
in the current TCB. Saves I/O old PSW in 
the current RB. Branches to the Trace rou- 
tine to store pertinent information in the 
trace table. Branches to the I/O Interrup- 
tion Supervisor to process the interrup- 
tion. When control is returned, clears the 
I/O switch (lORGSW) and enters the 
dispatcher. 

I/O Interruption Supervisor ; Is a part of 
the I/O Supervisor. Given control by the 
I/O First-Level Interruption Handler (I/O 
FLIH), it services the I/O interruption. 
It then returns control to the I/O FLIH. 

I/O Supervisor transient area ; The area of 
main storage in which the system error task 
loads a system I/O error- handling routine. 

Job file control blocks (JFCBs) for log 
data sets ; Contain descriptive information 
about the primary and alternate system log 
data sets. They are constructed and writ- 
ten on auxiliary storage by job management 
routines. Each JFCB is loaded in main 
storage when the DCB with the same ddname 
is opened. 

Link pack area queue (also called the link 
pack area control queue or LPACQ) ; Con- 
tains CDEs for modules stored in the link 
pack area of main storage. The link pack 
queue and the job pack queue together are 
called the contents directory. 

Log and WRITELOG Post routine ; (Figure 
7-10) Posts the ECB representing the appro- 
priate command. For log commands also 
issues a WTL macro instruction. 

Machine-Check Handler (MCH) ; Is available 
for System/360 Model 65, Model 65 Multipro- 
cessor {MCH/65) and Model 85 (MCH/85) and 
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Systein/370* Receives control via hardware 
loading of the machine check new PSW. This 
program consists of a resident module, and 
transient modules which reside on the SYSl. 
SVCLIB data set. It attempts to recover 
from a machine check interruption. 



MCH/65 first determines if the instruc- 
tion that was being executed when the 
machine-check interruption occurred can be 
retried, and, if retry is possible, re- 
executes the instruction. This function is 
handled by machine recovery facilities on 
the System/360 Model 85 and System/370. 
If, however, instruction retry is not poss- 
ible, MCH attempts to assess the damage to 
the program that was interrupted, and, in 
some models, repair that damage. 



If program damage is repaired, the MCH 
attempts to retry the interrupted instruc- 
tion. If the retry is successful, the MCH 
has recovered completely from the machine 
check interruption. 



If program damage cannot be repaired or 
instruction retjry is unsuccessful, the MCH 
can either continue partial system opera- 
tion or place the CPU in the wait state. 
The choice depends on the type of task that 
was current at the time of the machine 
interruption, the number of tasks that are 
affected, and the extent of the program 
damage. If limited system operation is 
possible, the MCH either abnormally ter- 
minates the current job step or sets the 
current task nondispatchable. If even 
limited system operation is not possible, 
because a critical system task is per- 
manently damaged, the MCH issues an error 
message and places the CPU in the wait 
state. ^ 

For a complete description of the 
Machine-Check Handler program consult the 
manual appropriate for the model being 
considered. 

• Machine-Check Handler for the Model 65 
PLM 

• Machine-Check Handler for the Model 85 
PLM 

• Machine-Check Handler for the System/ 
370 Models 135 and l'>5 

• Machine-Check Handler for the System/ 
370 Models 155 and 165 PLM 



^The operator may then load the SEREP pro- 
gram in order to format and print diag- 
nostic information from the CPU logout 
area. 



Master Scheduler Initialization routine ; 
(Figure 7-10) Is performed during nucleus 
initialization. Places appropriate unit 
control block name in the unit control 
table. Constructs an initial list of ECBs 
for the communications task. Determines 
which consoles are active. Gives control 
to the communications task Wait routine. 



Master Scheduler resident table ; Contains 
switches and pointers that are used by the 
Master Scheduler during nucleus initializa- 
tion. 

Nucleus Initialization Program (NIP) ; 
Initializes the resident part of the con- 
trol program and prepares main storage for 
control program operation. Receives con- 
trol from the IPL routine via a Load PSW 
instruction. Initializes nucleus tables, 
performs general system initialization, and 
sets up divisions of main storage. In the 
Model 65 Multiprocessing System, NIP also 
initializes those parts of the nucleus that 
are unique to multiprocessing. 

Open routine ; A data management routine 
that completes the specified data control 
block and prepares the associated data set 
for processing. Analyses input labels and 
creates output labels. 

Overlay Supervisor (nonresident module) ; 
(Chart CE) Directs loading of the specified 
overlay segment and any segments in its 
path that are not in main storage. When 
loading is complete and, the caller has 
issued a CALL macro instruction or a branch 
instruction, alters the entry tables of the 
loaded segments. The alteration permits 
future branches to the same points in the 
loaded segments without help from the Over- 
lay Supervisor. 

Overlay Supeiryisor (resident module) ; 
(Chart CE) Obtains the address of the seg- 
ment table for the overlay module. Ensures 
that the appropriate entry table contains 
the specified entry point name. Causes 
supervisor linkage to the nonresident 
module of the Overlay Supervisor. (The 
nonresident module was loaded by the common 
subroutines of Contents Supervision when 
the root segment of the overlay module was 
requested. ) 

Post routine ; (Chart BH) Places the cal- 
ler's post code into the specified ECB; 
sets the completion bit and clears the wait 
bit in the ECB. Also decreases by one the 
RB wait count for the waiting routine. If 
the new RB wait count is greater than zero, 
prepares for return of control to the call- 
er. If the new RB wait count is zero, 
branches to the Task Switching, then pre- 
pares for return of control to the caller 
or the newly readied routine. 



75H 



Program Check First-Level Interruption Han- 
dler ; (Charts AF,AG) Saves register con- 
tents in program check register save area 
in lower main storage. Then branches to 
the Monitor Call Interrupt Handler to filt- 
er out valid requests for monitoring. 
These requests are recorded by GTF (if 
active) , and control is returned directly 
to the user's program or the dispatcher if 
a task switch is necessary. If it is not a 
monitoring request, it is a valid program 
check and control is retiirned to the Pro- 
gram Check FLIH after recording the program 
check interruption in GTF, if GTF is 
active. If GTF is not active, and the 
trace option exists in the system, branches 
to the Trace routine to store irvformation 
in the Trace table. If the interrupted 
routine was operating in supervisor state, 
gives control to the ABTERM Prologue rou- 
tine - If the interrupted routine was 
operating in problem-program state, deter- 
mines if the address of a program interrup- 
tion element (PIE) is in the current TCB. 
If a PIE address is not in the TCB, 
branches to the ABTERM Prologue routine. 
Otherwise, stores the program old PSW and 
registers 2-14 in the PIE. If a program 
interruption control area (PICA) is not in 
effect or is being used for a previous pro- 
gram interruption, the routine branches to 
the ABTERM Prologue routine. Otherwise, 
places the entry point address of the 
interrupted routine in the program old PSW 
and branches to a user-written error- 
handling routine. 



In a Model 65 Multiprocessing System, 
determines if the interruption was caused 
by an SSM instruction. If it was, sets the 
supervisor lock byte if complete enablement 
is not indicated, records the interruption 
from the SSM instruction in the GTF trace 
area, if GTF is active, and returns control 
to the interrupted routine. Before proces- 
sing other types of program interruptions, 
sets the supervisor lock byte. 



Program Fetch routine ; (Chart CD) Obtains 
needed storage space, initializes tables 
and an extent list, initiates I/O opera- 
tions, and loads the specified module or 
overlay segment into main storage. Per- 
forms any needed relocation of address con- 
stants. Computes the module's relocated 
entry point address and returns it to the 
caller. Also returns the address of the 
module's extent list. 



Program Fetch Channel-End Appendage rou- 
tine ; (Chart CD) Determines if all buffers 
are full and whether the entire module or 
overlay segment has been loaded. Receives 
control from and returns control to the I/O 
Interruption Supervisor. 



Program Fetch PCI Appendage routine : 
(Chart CD) After each PCI interruption, it 
tests a record in the current RLD buffer. 
When necessary, it causes a channel-program 
switch between two-record mode and single- 
record mode. Such switch is necessary if 
an RLD or control record does not follow a 
text record on auxiliary storage. When the 
last record is being read, posts a fetch 
ECB. Receives control from and returns 
control to the I/O Supervisor. 

Purge Timer routine ; (Chart LD) Is invoked 
by the EOT routine or ABENDl during a norm- 
al or abnormal termination. Tests a timer 
queue element (TQE) , if one belongs to the 
terminating task. If the TQE is not on the 
timer queue, issues a FREEMAIN macro 
instruction to free the space the TCQ occu- 
pies. If, however, the TQE is on the timer 
queue, the routine branches to the Timer 
Second-Level Interruption Handler 
(lEAQTDOO) to cancel the interval request 
and remove the TQE from the timer queue. 

Reply Purge routine ; Refer to the WTOR 
Purge routine. 

Release Loaded Programs routine ; (Chart LE) 
Is invoked by the EOT routine or ABEND16 
during a normal or abnormal termination. 
Frees load list elements for the terminat- 
ing task and reduces the use/responsibility 
count in each related CDE. Branches to 
CDHKEEP in the CDEXIT routine to test the 
reduced use/responsibility count and per- 
form, if necessary, further module cleanup. 

Release Main Storage routine ; (Chart LE) 
Is invoked by the EOT routine or ABENDl 6 
during a normal or abnormal termination. 
Releases main storage exclusively allocated 
to the terminating task. The task's sub- 
pool queue elements (SPQEs) are used to 
free unshared subpools. The SPQEs are 
removed from the task's main storage queues 
and their space is freed. In addition, if 
the job step task is being terminated, the 
routine branches to CDDESTRY in the CDEXIT 
routine. CDDESTRY frees main storage occu- 
pied by each module in the job pack area, 
its extent list, and its CDEs (major and 
minor) . 

Restart routine ; (Charts JJ-JY) Reads and 
interprets records from a checkpoint entry 
to restore a previously executed task to 
its main storage region, open and reposi- 
tion its data sets, and restore task con- 
trol blocks and queues so that it may be 
restarted within a job step. 

Rollout/Rollin module ; (Charts DC-DI) 
Schedules rollout when an unconditional 
GETMAIN cannot be satisfied with space from 
the job step's region; schedules rollin 
when all space in a borrowed region is 
freed. 
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SEGLD Processor routine ; (Chart CE) Is a 
part of the Overlay Supervisor nonresident 
module. Is attached to operate as a sub- 
task. Scans the segment table. Invokes 
the Program Fetch routine to load each 
indicated segment of an overlay module. 
Posts an ECB for the Overlay Supervisor 
when all indicated segments have been 
loaded. 



SERO routine (resident module) ; (Chart AK) 
Model- independent part of the SERO routine. 
Is entered after a machine check interrup- 
tion. Saves register contents and other 
indicative information, halts I/O activity, 
and causes entry to the appropriate model- 
dependent part of the routine. 



SERO routine (nonresident module) ; (Chart 
AK) Model- dependent modules, one of which 
is used with the corresponding model of IBM 
System/360. Collects information about the 
status of the system at the time of the 
interruption, writes tht information onto 
the SYSl.LOGREC data set, and places the 
CPU into a wait state. 



SERl routine ; (Charts AL,AM) Model- 
dependent modules, one of which is used 
with the corresponding model of IBM System/ 
360. Collects information about the status 
of the machine at the time of the interrup- 
tion and writes the information onto the 
SYSl.LOGREC data set. Then, either causes 
an abnormal termination of the job step, or 
places the CPU into the wait state, depend- 
ing on the severity of the error condition. 

Set Status routine ; (Chart BW) Sets all 
tasks of the specified job step nondis- 
patchable by setting the TCBPRO flags in 
their TCBs. 

SHOLDTAP routine ; In a Model 65 Multi- 
processing System, issues a write direct 
instruction which initiates an external 
interruption on the second CPD in a multi- 
processing system. The STMASK byte indi- 
cates the routine that gains control on the 
second CPU as a result of the interruption. 

SMF EXCP Counting routine ; (Chart MM) 
Counts and records the number of references 
to user data sets. Compares EXCP count to 
output limit specified for SYSOUT data 
sets. 

SMF Storage routines ; (Chart DA) Records 
the number of 2K blocks required within the 
region for problem progrcun execution. 

SMF Time/Output Limit Expiration routine ; 
(Chart MN) Provides an interface with a 
user time limit expiration routine and with 
a user output limit routine. 



SMF Wait Time Collection routine : (Chart 
MO) Collects and records system wait time 
information. 

SPIE routine ; (Chart BF) Places into the 
caller's TCB an indirect pointer to the 
specified user error-handling routine. 
Either locates an existing program inter- 
ruption element (PIE) or creates a new one, 
and places its address in the caller's TCB. 
Then places in the PIE the address of the 
associated program interruption control 
area (PICA). The PICA contains the address 
of the user error- handling routine. 

STAE Service routine ; (Charts BP-BV) 
Creates a STAE control block which contains 
the address of a user^written STAE exit 
routine and parameter list. When an ABEND 
is scheduled for a task that has issued 
STAE, the ABEND routine invokes the ABEND/ 
STAE interface routine, which purges the 
task's I/O, schedules the STAE exit rou- 
tine, and returns control to the user at 
the STAE exit routine address. Upon com- 
pletion of the STAE exit routine, the 
ABEND/STAE interface routine either returns 
control to ABEND to terminate the task or 
schedules the user^written STAE retry 
routine. 

Stage 1 Exit Effector ; (Chart BK) Creates 
and initializes an interruption request 
block (IRB) to schedule and control execu- 
tion of a user exit routine. 

Stage 2 Exit Effector ; (Chart BL) Starts 
the scheduling of entry to a user exit rou- 
tine by placing the specified queue element 
(IQE or RQE) on the appropriate asynch- 
ronous exit queue. 

Stage 3 Exit Effector ; (Chart BM) Com- 
pletes the scheduling of a user exit rou- 
tine. It does this by transferring an IQE 
or RQE from an asynchronous exit queue to 
the queue belonging to the appropriate IRB 
or SIRB. Queues the IRB to the appropriate 
TCB. Queues the SIRB to the system error 
TCB. contains an error fetch sequence 
(similar to the TA Fetch routine) that 
causes a needed but unavailable system I/O 
error- handling routine to be loaded. The 
error^handling routine is loaded in the I/O 
Supervisor transient area. 

STIMER routine ; (Charts EB-EF) Builds and 
places on the timer queue the elements that 
represent specified time intervals. 

SVC First-Level Interruption Handler ; 
(Chart AA) Saves the caller's register con- 
tents. Branches to the GTF routines, if 
active or the Trace routine to record 
information about the SVC interruption. 
Determines from the SVC table the type of 
SVC routine to be given control. If a 
type-1 routine, gives control to the rou- 
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tine. If a type-2, 3, or 4 routine, gives 
control to the SVC Second- Level Interrup- 
tion Handler. 

SVC Purge routine ; Is part of the I/O 
Supervisor. Is invoked by ABENDl during an 
abnormal termination. Removes from system 
queues the request elements (RQEs) that 
represent I/O requests issued for the ter- 
minating task. Issues a Halt I/O instruc- 
tion to stop the task's I/O operations. 

SVC Second- Level Interruption Handler ; 
(Chart AB) is entered from the SVC First- 
Level Interruption Handler. Constructs a 
supervisor request block (SVRB) from pre- 
viously allocated space and initializes the 
SVRB. Moves the caller's register contents 
from lower main storage to the SVRB. 
Queues the SVRB to the TCB for the caller's 
task. If a resident (type-2) SVC routine 
is needed, branches directly to the 
routine. 

If a nonresident (type 3 or 4) SVC rou- 
tine is needed, determines if the routine 
is already in a transient area block (TAB) . 
If the routine is in a TAB, places the SVRB 
on a user queue and branches to the TAB. 
If the routine is not in a TAB, examines 
the transient area control table and the 
user queues to find an available TAB. If 
it finds an available TAB, places those 
SVRBs "using" the TAB into a wait condi- 
tion, places the new SVRB on the user queue 
for the TAB, makes the new SVRB wait, 
readies a transient area fetch task to load 
the SVC routine into the TAB, invokes the 
Task Switching routine, and branches to 
theDispatcher. If, however, an available 
TAB cannot be found, places the new SVRB 
into a wait condition, indicates the need 
for a task switch, and branches to the 
Dispatcher. 

System Error TCB ; The system TCB under 
whose control system I/O error-handling 
routines are loaded into the I/O Supervisor 
transient area and then executed. 

Task Removal routine ; In a Model 65 Multi- 
processing System, determines if the cur- 
rent task on the second CPU in a multipro- 
cessing system has been set nondispatch- 
able. If it has, causes the dispatcher to 
gain control on the second CPU and dispatch 
a new task. 

Task Switching routine ; (Charts BN, BO) 
Determines if a newly readied task, which 
may be of higher dispatching priority than 
the current task, should be dispatched in 
place of the current task. Compares the 
dispatching priority of the specified ready 
task with that of the next-to-be-dispatched 
task. (The address of the TCB for the 
next^to-be-dispatched task is stored in the 
"new" TCB pointer, lEATCBP.) If the speci- 



fied task's priority is higher, places its 
TCB address into the "hew" TCB pointer. If 
the specified task's priority is lower, 
makes no change. If the task priorities 
are equal, places in the "hew" TCB pointer 
the address of the TCB positioned higher on 
the TCB queue. 

In a Model 65 Multiprocessing System, 
determines if the newly readied task should 
be dispatched in place of the current task 
on either CPU. Determines which of the two 
next-^to-be-dispatched tasks has the lower 
dispatching priority, and compares the 
lower task with the newly readied task. If 
the newly readied task has a higher priori- 
ty, places its TCB address into the "new" 
TCB pointer. 

TESTRAN Interpreter ; Is the part of the 
control program that interprets requests 
for test services. Is invoked by either 
the common subroutines of Contents Supervi- 
sion or the Overlay Supervisor if the 
loaded module or segment is being tested. 

Time routine ; (Charts EA,EE) Determines 
the current date and time of day and 
returns both values to the caller. Places 
the time of day into register and the 
date into register 1. 

Timer Second-Level Interruption Handler ; 
(Charts ED, EH) Is entered from the External 
First-Level Interruption Handler after a 
timer-caused interruption. Determines what 
action to take by removing and examining 
the topmost timer queue element (TQE) on 
the timer queue. May prepare entry to a 
user-written routine or posts a specified 
ECB. Resets the interval timer, using the 
value contained in the new top TQE. 



Trace routine; 



Builds the trace table, a 
The trace table describes 



system option, 
conditions at each SVC interruption, 
external interruption, program interrup- 
tion, and at each issuance of a Start I/O 
instruction, and each execution of the Dis- 
patcher. The Trace routine is invoked by 
the SVC First-Level Interruption Handler 
(SVC FLIH), the I/O FLIH, the External 
FLIH, the Program Check FLIH, and the 
Dispatcher. 

Transient Area Availability Check routine ; 
(Chart AD) Is invoked by the SVC Second- 
Level Interruption Handler. Examines the 
transient area control table and the user 
queues to locate a transient area block 
that may be overlaid by a SVC routine. 

Transient Area Exit routine ; (Chart KC) Is 
invoked by the Exit routine or by the com- 
mon subroutines of Contents Supervision. 
Prepares for return of control to the call- 
er of a type-2, 3, or 4 SVC routine. Moves 
saved register contents from the exiting 
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routine's SVRB to the TCB for the caller's 
task. For an exiting nonresident routine 
(type 3 or 4) , removes the SVRB from its 
transient area user queue. 

Transient Area Fetch routine ; (Chart AE) 
Is entered when the SVC Second-Level Inter- 
ruption Handler, or the Transient Area XCTL 
routine, or the Transient Area Refresh rou- 
tine determines that a nonresident SVC rou- 
tine must be loaded. Locates the needed 
routine, and uses the Program Fetch routine 
to load the needed routine into the avail- 
able transient area block. Is controlled 
by a high-priority system TCB, called a 
transient area fetch TCB. 

Transient Area Refresh routine ; (Chart KD) 
Determines if an SVC routine that occupied 
a transient area block but was overlaid 
should be reinstated. If so, schedules 
reloading of and entry to the routine. 

Transient Area XCTL routine ; (Chart CA) 
Prepares for entry to another module of a 
multi-module (type-4) SVC routine. Rein- 
itializes the appropriate SVRB. If the 
needed module is in a transient area block, 
schedules entry to it. Otherwise, locates 
(if possible) an available transient area 
block and schedules loading of and entry to 
the module. If a transient area block is 
not available, places the SVC routine's 
SVRB in the wait condition, queues the SVRB 
to a queue of waiting SVRBs, and indicates 
the need for a task switch. 

TTIMER routine ; (Charts EC, EG) Determines 
and places into register the time remain- 
ing in a previously requested time inter- 
val. Optionally Ccuicels a previously 
requested interval. 

Type-l Exit routine ; (Chart KA) Routes 
control to the interrupted routine or to 
the Dispatcher. Restores saved register 
contents and returns control to the inter- 
rupted routine, if the need for a task 
switch is not indicated. (A task switch is 
not indicated if the addresses in the two 
TCB pointers, lEATCBP and IEATCBP+4, are 
equal. ) If the need for a task switch is 
indicated, moves saved register contents to 
the current TCB, and gives control to the 
Dispatcher to perform the task switch. 

Validity Check routine ; Validates user- 
supplied addresses. Checks addresses for 
fullword boundary alignment, determines if 
the addresses lie within the limits of main 
storage, and tests if the addresses specify 
storage areas whose storage protection keys 
match the protection key in the caller' s 
TCB. 

Vary Storage Offline subroutine (IFSVRYOF) ; 
Processes requests to remove an area from 
available main storage in a multiprocessing 



system. Alters the FBQE(s) and marks the 
area unavailable in the FSSEMAP. 



Wait routine ; (Chart BG) Determines if any 
of the specified events have occurred. If 
all have occurred, prepares for return of 
control to the caller. If all the speci- 
fied events have not occurred, makes the 
caller wait by placing the appropriate wait 
count into the caller's RB. Then indicates 
the need for a task switch. 



Write-to- Log routine ; (Charts GB,GC) 
Schedules servicing of a request to write a 
message onto the system log. Places the 
message into a log element Eind adds the 
element to a chain of log elements. Posts 
the system log ECB to signify receipt of 
the message. 

Write-to-Operator routine ; (Charts FB,FC) 
Prepares buffers and posts the communica- 
tions task ECB. 

Write-to-Proqrammer routine ; For a WTO or 
WTOR macro instruction with a ROOTCDE=11 
parameter, puts the message into the job's 
system message class output data set. 

WRITELOG Available Log Data Set routine ; 
(Figure 7-10) Sets a bit in the log control 
area to indicate availability of either the 
primary or alternate system log data set. 

WRITELOG Dispatch routine ; (Figure 7-10) 
Initializes a job file control block (JFCB) 
and a data set block (DSB) for the speci- 
fied primary or alternate log data set. 
Places both the JFCB and DSB on the job 
queue. 

WRITELOG Get Region routine ; Obtains the 
region to be used for the log dispatcher 
task. 

WRITELOG Log Initialization routine ; 
(Figure 7-10) Searches the catalog to loc- 
ate the two log data sets. Creates a data 
control block (DCB) for and opens the pri- 
mary log data set. Initializes the log 
control area. 

WRITELOG Log Writer routine ; (Chart GA) 
Writes messages onto the system log data 
set. In response to a WRITELOG command, 
causes the appropriate log data set to be 
transferred to an output device by a system 
output writer. 

WRITELOG Master Wait routine ; (Figure 
7-10) Passes control to the Log Writer rou- 
tine when the system log ECB is posted. 

WRITELOG Open Device routine ; (Figure 
7-10) Opens the specified system output- 
writer data set. 
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WTOR Purge routine (also called Reply Purge 
routine) ; Is invoked by the EOT routine, 
ASIR5, or ABENDl during a normal or abnorm- 
al termination. Disposes of outstanding 
messages and replies to messages by remov- 
ing elements from the buffer queue and the 
reply queue. 
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APPENDIX A: DIAGNOSTIC AIDS IN ABEND PROCESSING 



If an error occurs during ABEND proces- 
sing, the result is usually an invalid 
recursion that leads to an entry into DAR. 
The dump taken by DAR at this time is inva- 
luable in determining the cause of the 
recursion; however, a stand-alone or ABEND 
dump can also be helpful. Generally, the 
programmer only needs to examine the fol- 
lowing areas to get some idea of the 
problem: 

1. PSW and registers at ABEND. (These 
may be in one or more places depending 
on the type of dump. ) 

2. The RB chain of the terminating TCB. 

3. A trace table with a sufficient number 
of entries. 

Most often, the important registers are 
found in DARl's (lEAQTMOL) SVRB register 
save area. The interruption handlers' 
register save areas, of which the program 
interruption save area is the most impor- 
tant, sometimes can give an idea of pre- 
vious happenings. (The easiest way to find 
the save area is to examine the machine 
code in the dump imtil the STM instruction 
is located for the pairticular interruption 
handler.) 

The registers in ABTERM's save area are 
helpful in understanding an ABEND initiated 
by a type-1 SVC because there is often use- 
ful information left in that SVC's regis- 
ters when it branches to ABTERM. 

Because of the nature of ABEND'S purges, 
invalid recursions often involve the GET- 
MAIN or FREEMAIN functions, usually invoked 
via SVC 10 or its branch entry. In such a 
case, ABTERM's save area often contains the 
following useful information: 

Register 2 - The invalid main storage 
control block detected. 

Register 5 - The subpool number. 

Register 8 - GETMAIN/FREEMAIN base. 

Register 10 - The number of bytes to be 
freed or requested. 

Register 11 - The area to be freed or 
requested. 

Register 12 - The valid SPQE or DQE 
address that the main 
storage control block in 
register 2 was chained to. 



If this is zero, the main 
storage queues may have 
been exhausted in attempt- 
ing to find an allocation 
for the referenced 
storage. 



INTERNAL ABEND DEBOGGING FEATURES 

The ABEND (SVC 13) modules contain 
internal features which are present for the 
express purpose of debugging ABEND. These 
features are consistent across ABEND and 
ASIR. Although consistency is not present 
across all DAR modules, ABEND/DAR inter- 
faces have been altered to ensure that some 
debugging information is still available 
when ABEND regains control from DAR. The 
general debugging aids follow: 

1. When an ABEND (SVC 13) module passes 
control, via an XCTL, to another SVC 
13 module, the last four bytes of the 
CSECT name of the module issuing the 
XCTL are placed in register 0. 
Register 1 contains the last four 
bytes of the CSECT name of the module 
that gains control after the XCTL. A 
glance at the trace table tells a sys- 
tem programmer exactly which SVC 13 
modules have received control and the 
order. Note that all SVC 13 modules 
end in C'*01C' \*iere * is any digit or 
number of the universal alphabet. 

2. At entry to ABENDO for a true ABEND, 
the extended save area of the ABEND'S 
SVRB is zeroed out. Any nonzero value 
in the ESA must have been put there by 
ABEND. 

3. The last two words of the ESA contain: 

C ABEND ' , C ' * ' , X ' SSSO ' 

where 

* is the fifth character in the 
name of the ABEND CSECT that last 
got control , and 

SSS is the system completion code 
for the ABEND that is being pro- 
cessed by the ABEND SVRB. If SSS 
is 000, either the ABEND was a user 
ABEND, or the system completion 
code was not available at the time 
the first ABEND module gained 
control. 
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EXAMPLE ; If the ABEND SVRB pointed to by 
the TCB in an ABEND dump contained the 
hexadecimal characters •C1C2C5D5CUF90C10' 
in its last two words, the ABEND module in 
control at the time of the dump was 
IGC0901C, and it was processing a OCl pro- 
gram check. 



its ESA, there was 
OCl program check, 
the programmer may 



If there were another ABEND SVRB on the 
chain with a value of 'C1C2C5D5C4F48060' in 

an ABEND previous to the 
In analyzing this dump, 
conclude that there must 
have been an ABEND recursion; the previous 
ABEND was an 806 ABEND, and the last module 
to have control in the previous ABEND was 
IGC0401C- 

The system programmer might use this 
debugging information to determine the fol- 
lowing chain of logic in limiting the like- 
ly problem area; 

1. The last ABEND module in control was 
IGC0401C. It either terminated 



abnormally on a program check, or some 
routine called on its behalf ter- 
minated on a program check. 



2. The ABEND dump was taken on the recur- 
sion; thus ABEND was prepared to 
handle the recursion validly. 

3* IGC0401C has only one valid recursion 
- across the Write-to-Programmer rou- 
tine. If WTP should terminate abnorm- 
ally, a valid recursion configuration 
flag is set. 

4. The programmer may conclude that the 
Write-to-Programmer routine must 
itself have abnormally terminated via 
a program check, or some system rou- 
tine called on its behalf abnormally 
terminated. The system programmer 
would then check other information 
(such as the RB chain) to verify this 
conclusion, and continue by checking 
for the error in WTP. 
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description of 252-253 
entry point name of 737 
flowchart of 700 
module name for 724 

general description 251 

relationship to ABEND 654 

synopsis of 751 
Data set descriptor records 



definition of 175 
format of 179 
Data set directory entry 

as used by common subroutines of 

Contents Supervision 74 
as used by the Program Fetch routine 98 
format of 310 
Data Set Processor routines 
description of 185-186 
entry point names of 743-744 
flowcharts of 607-611 
module names for 724 
DCB parameter for LINK, LOAD, or XCTL 

processing 76 
DCM (see Display control module) 
DD statement for dump data set 234-235,238 
DEB queue 

use of to close data sets 

during abnormal termination 241-242 
during normal termination 200 
Decimal simulator routines for Models 91 
and 195 

Add, subtract, Zero-and-Add 
description of 263 
entry point name of 737 
flowchart of 706-707 
Analyzer/End 

description of 267,269 
entry point names of 737 
flowchart of 710 
Compare Decimal 

description of 267 
entry point name of 737 
flowchart of 705 
Divide Decimal 

description of 266-267 
entry point name of 737 
flowchart of 709 
Multiply Decimal 

description of 263,265-266 
entry point name of 737 
flowchart of 708 
Simulator Control 

description of 259,262-263 
entry point name of 737 
flowchart of 704 
synopsis of 751 
Deferring a request for a transient SVC 

routine 19-20 
Deferring the request for an unavailable 

module 74 
Delete routine 

description of 88-89 
entry point name of 737 
flowchart of 458 
module name for 727 
synopsis of 751 
Delete routines (DIDOCS) (see 

Communications task) 
Dequeue routine 

description of 58-62 
entry point name of 737 
flowcharts of 427-428 
module name for 727 
synopsis of 751 
Dequeue TCB routine 

entry point name of 737 
flowchart of 645 
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function of 

during abnormal termina-tion 250 
during normal termination 202 

module name for 716 

synopsis of 751 
Descriptor queue element (DQE) 

construction of 111-112 

format of 324 

normal release of 130 
Detach routine 

description of 40-42 

entry point name of 737 

flowchart of 421 

module name for 727 

synopsis of 751 
Device Independent Display Operator Console 

Support (see Communications task) 
Diagnostic aids 760-761 
DIDOCS (see Communications task) 
Direct SYSODT Writer 233 
Dispatcher 

description of 193-198 

entry point name of 737 

flowcharts of 624-642 

module name for 719 

synopsis of 751 
Dispatching priority 

changing of 36 

use of by the Dispatcher 194 
Display Control Module 160-161 

format of 337 
Device Independent Display Operator Console 

Support (see Communications task) 
DJSEARCH Subroutines 

flowcharts of 627,633 
DOS Tape Data Set Processor 

description of 185 

entry point name of 743 

flowchart of 615-616 

module name for 724 
DPQE (see Dummy partition queue element) 
DQE (see Descriptor queue element) 
DQLOAD subroutine, function of 79 
DQTCB (see Dequeue TCB routine, function 

of) 
Dummy Data Set Processor 

description of 183 

entry point name of 743 

flowchart of 604 

module name for 723 
Dummy partition queue element (DPQE) 

construction of 109 

format of 328 
Dummy request block for the system error 

task 66 
Dump, sample 368 
Dump data set 

determining whether to open 234 

ensuring that the dump data set remains 
open for the duration of the job 
step 235-236 

indicating whether the dump data set has 
been opened 236 

preparing to open 235 
Dumping 

contents directory entries 215 

data extent blocks (DEBs) 215 

dynamically acquired storage 218-219 



extent lists 215 

GTF control and error records 220 

GTF trace data 220 

load modules represented by CDEs 219 

main storage queue elements 215-216 

nucleus of main storage 218-219 

old PSW 215 

problem-program register save areas 217 

QCBs, QELs, and save areas belonging to 
IRBs 216 

register contents 218-219 

request blocks 215 

storage acquired for the task 219-220 

task I/O table (TIOT) 215 

task's load list 215 

TCB 215 

trace table 220 
Dumps (see Dumping, and Sample dump) 
Dynamic DD entries 

clearing of 245 

specification of 235 
Dynamic Device Reconfiguration (DDR) 

description of 2,26 

entry point names of 737-738 

error routine fetch processing 66-67 

model dependency 2,25 

module names for 725,726,728,729 

synopsis of 751 



ECB (see Event control block) 
End-of-Task (EOT) routine 

description of 199-203 

entry point name of 739 

flowchart of 643 

module name for 716 

synopsis of 751 
End-of-Task Exit routine (ETXR) 

scheduling of 202 
ENQ routine (see Enqueue routine) 
ENQ/DEQ Purge routine 

description of 244 

entry point name of 739 

module name for 717 

synopsis of 752 
Enqueue routine 

description of 49-58 

entry point name of 739 

flowchart of 427-428 

module name for 727 

synopsis of 751 
ENTAB (see Entry table) 
Entry points 

directojry of 733-747 

embedded, informing the supervisor 
of 87-88 
Entry table (ENTAB) 92 

format of 323 
ENTRY2 240 
Environment Recording Edit and Print 

Service Aid (IFCEREPO) 26 
Erase Phase routine 

entry point name of 739 

function of 

during abnormal termination 250 
during normal termination 203 

module name for 717 

synopsis of 752 
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ERFETCH 66 

Error fetch sequence 66 

ETXR operand 

effect vdien ATTACH routine is 
executed 31 
ETXR scheduling 202 
Event control block 

format of 302 

(also see Posting an event control 
block) 
EXCP Supervisor 

entry point name of 740 

function of 100 

module name for 719 

synopsis of 752 
Exit Effector (see Stage 1 Exit Effector, 
Stage 2 Exit Effector, and Stage 3 Exit 
Effector) 
Exit routine 

description of 187-192 

entry point name of 7U0 

flowchart of 618-620 

module name for 726 

synopsis of 752 
Extended SVC Router (ESR) 

description of 15 

entry point names of 739 

flowchart of 398 

module name for 728 

synopsis of 752-753 
Extent list 

construction of 97-99 

definition of 191 

normal release of 191-192 

(also see scatter extent list and block 
extent list and note list) 
External First-Level Interruption Handler 

description of 22-23 

entry point name of 740 

flowcharts of 404-405 

module name for 717 

synopsis of 753 
External FLIH (see External First- Level 

Interruption Handler) 
External interruptions 22-23 
Extract routine 

description of 39-40 

entry point names of 740 

flowchart of 420 

module names for 727 

synopsis of 753 



Fail soft storage element map (FSSEMAP) 

format of 347 
FBQE (see Free block queue element) 
First CPU signal routine 

description of 72 

entry point name of 740 

module name for 716 
First-time logic switch (see Program 

interruption element) 
FQE (see Free queue element) 
Free block queue element (FBQE) 

construction of 109,130 

definition of 109 

format of 328 
Free queue element (FQE) 



construction of 112,130 

format of 325 
FREEMAIN macro instruction 

list structure of 106 

types of SVC instructions for 106 
FREEMAIN routine 

description of 129-130 

entry point names of 740 

flowchart of 463-465 

module name for 716, 727 

synopsis of 753 
FSSEMAP 347 



Generalized Trace Facility (GTF) 

description of 8,273 

dump of trace data 220 

external storage option 273 

internal storage option 273 

synopsis of 753 
GETMAIN macro instruction 

list structure of 106 

types of SVC instructions for 106 
GETMAIN routine 

description of 106-107 

entry point names of 740 

flowchart of 463-465 

module name for 716,727 

synopsis of 753 
GOVRFLB 128 

format of 326 
GTF (see Generalized Trace Facility) 



HOOK macro instruction 

resume GTF trace 239,253 
suspend GTF trace 238 



IFCEREPO 26 
I/O block 

for the I/O supervisor transient area 
entry point name of 740 
module name for 717 

for the SVC transient areas 
entry point names of 746 
module name for 731 
I/O First-Level Interruption Handler 

description of 24 

entry point name of 740 

flowchart of 406 

module name for 717 

synopsis of 753 
I/O FLIH (see I/O First-Level Interruption 
Handler) 
I/O Interruption Supervisor 

description of 24 

entry point name of 740 

module name for 719 

synopsis of 753 
I/O interruptions 24 
I/O requests and I/O operations in process 

purging of 227,230 
I/O supervisor transient area 

entry point name of 740 

synopsis of 753 
I/O switch (lORGSW) 24 
Identify routine 
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description of 87-88 

entry point name of 740 

flowchart of i»56~t57 

module name for 727 

synopsis of 753 
lEADQTCB 202,250 
lEAHKAD 38 

lEAQABL (see Release Loaded Programs 
routine) 
lEAQERA (see Erase Phase routine) 
lEAQSPET (see Release Main Storage routine) 
lEAQTAQ (see Transient area control table) 
lEASCSAV 11 
lEATCBP 187 
lEATYPEl 

use of during ABTERM processing 211 
lEEVLIN routine 172-174 

(see also WRITELOG Log Initialization 
routine) 
lEEVLOPN routine 172-174 

(see also WRITELOG Open Device routine) 
lEEVWAIT routine 172-174 

(see also WRITELOG Master Wait routine) 
Informing the supervisor of an embedded 
module entry point 85 
Initial Program Loading (IPL) routine 

entry point name of 740 

module name for 731 

synopsis of 753 
Inter- Par iit ion Post 

cancellation for TCAM data sets 243 

cancellation for TSO tasks 244 

check by Post routine 47,48 
Interruption handling 10 

(see also SVC interruption handling. 
Program interruptions. External 
interruptions, I/O interruptions, and 
Machine interruptions) 
Interruption queue element 

construction of 31-32 

definition of 63 

format of 306 

initialization of 32 

normal release of 68 

queuing of 64 
Interruption request block 

abnormal release of 248 

construction of 64 

definition of 4 

format of 293 

normal release of 192 
lOB (see I/O block) 
lOBSEEK field 125 
lORGSW (see I/O switch) 
IQE (see Interruption queue element) 
IQE list (AEQJ) 64 

IRE (see Interruption request block) 
ISAM and BDAM Data Set Processor 

description of 186 

entry point name of 743 

module name for 724 



JFCB Processor routines 
description of 182-183 
entry point names of 743 
flowchart of 603 
module name for 723 



Job file control blocks for log data 

sets 174,741 
Job pack area control queue 4-5,75 
Job pack area queue (see Job pack area 

control queue) 
Job Step Timing 

in Dispatcher routine 

description of 197-198 
flowchart of 625-626 
in Post routine 

description of 47 
flowchart of 425-426 
in Wait routine 

description of 46-47 
flowchart of 423-424 
in Timer Second-Level Interruption 
Handler 

description of 141-142 
flowchart of 479-480 
JPACQ (see Job pack area control queue) 



ICS (2361 Core Storage) (see Main Storage 

Hierarchy Support) 
Light Pen/Cursor routine (see 

Communications task) 
Limit priority 36 
Link pack area 4 
Link pack area control queue 

definition of 4 

search of 81,84 
Link pack area queue (see Link pack area 

control queue) 
Load list 

definition of 5,80 

purging of 248-249 
Load list element 

abnormal release of 248-249 

construction of 74 

format of 310 

normal release of 86 
Local system queue area 107,129,135 
Log and WRITELOG Post routine 

entry point name of 741 

module name for 722 

synopsis of 753 
Log command 172-174 
Log data sets 

job file control blocks (JFCBs) for 
entry point name of 741 
module name for 721 
LPACQ (see Link pack area control queue) 
LSQA (see Local system queue area) 



Machine-Check Handler 

Contents Supervision with 78 
entry point names of 741 
general description 2,25-26,29 
module names for 729-730 
synopsis of 753-754 

Machine- check record (SERO and SERl) 
construction of 25 
format of 364 

Machine interruptions 
definition of 1 
recovery options for 24-29 

Main storage 
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allocation of 106-107 
purging of 201,249 
Main Storage Hierarchy Support 

Contents Supervision service routines 

with 74 
description of 5,8 
GETMAIN routine with 99,111 
loading of overlay module with 89 
Major CDE (see Contents directory entry) 
Major QCB (see Queue control block) 
Master Scheduler Initialization routine 
entry point name of 741 
module name for 721 
synopsis of 754 
Master scheduler resident table 
entry point name of 741 
module name for 721 
synopsis of 754 
Master scheduler task control block (TCB) 
entry point name of 7Ui 
module name for 717 
MCH (see Machine-Check Handler) 
MCS (see Multiple Console Support) 
Message routines (see Communications task) 
Minor CDE (see Contents directory entry) 
Minor QCB (see Queue control block) 
Model 85 I/O routine (see Communications 

task) 
Model 85 operator console with CRT display 

suppo3:t (see Communications task) 
Models 91 and 195 

Decimal Simulator routines (see Decimal 

Simulator routines) 
Program Check First-Level Interruption 
Handler routine for 
description of 22 
flowchart of 403 
SERl routine for 

description of 27-29 
entry point name of 744 
flowchart of 409-410 
module name for 717 
Mount/Verify routines 

description of 183-184 
entry point names of 743 
flowcharts of 605-606 
module name for 723,724 
MPCVT (see Multiprocessing communications 

vector table) 
MSSLOOP 229 
Multiple Console Support 

detailed routine descriptions 
Attention Handler module 
description of 151 
entry point name of 734 
flowchart of 485 
module name for 719 
Console Support routines 156-158 
Console Initialization module 
description of 151 
entry point name of 735 
flowchart of 488-492 
module name for 720 
synopsis of 750 
Console Switch modules 
description of 153-154 
entry point names of 735 
flowchart of 498-503 



module name for 722,723 
Device Interface routine 
description of 154-155 
entry point name of 735 
flowchart of 504-506 
module name for 719 
DOM Service module 
description of 155 
entry point name of 735 
flowchart of 510 
module name for 719 
External Interruption Handler 
description of 151 
entry point name of 735 
flowchart of 485 
module name for 719 
Graphic Console Initialization Module 
description of 153 
entry point name of 740 
flowchart of 493 
module name for 721 
Mini-Router Module 
description of 153 
entry point name of 436 
module name for 725 
NIP Message Buffer Writer Module 
description of 155 
entry point name of 436 
module name for 726 
Router module 

description of 153 
entry point name of 736 
flowchart of 497 
module name for 720 
Dnit Control module 
description of 156 
entry point name of 736 
module name for 721 
WTO/R Service Module 
description of 155 
entry point name of 736 
flowchart of 507-509 
module name for 720 
general description 149-151 
Reply Queue Element (RQE) for 329 
Unit Control Module MCS prefix 349 
Write Queue Element (WQE) for 354 
Multiple-Line Write to Operator 

macro expansion 362 
Multiple-Line Write- to- Operator routines 

(see Communications task) 
Multiprocessing communications vector table 
(MPCVT) 

format of 346 
Multiprocessing 

ABDUMP routine with 218,220 
description of 7-8 
Dispatcher with 193-195 
External FLIH routine with 
description of 23-24 
flowchart of 405 
First CPU Signal routine with 72 
FREEMAIN routine with 129-130 
I/O FLIH routine with 
description of 24 
flowchart of 406 
Job Step Timing with 
description of 198 
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flowchart of 625-626 
Machine-Check recovery with 29 
Program Interruption FLIH routine with 

description of 21-22 

flowchart of 401-'»02 
Set Status routine with 71 
Stage 3 Exit Effector with 66 
SVC FLIH routine with 

description of 12 

flowchart of 396 
Task Switching routine with 69-70 
Type 1 Exit routine with 187 
Must- complete status 
clearing of 61 

DAR processing for tasks 251-252 
meaning of TCB flags for 56 
setting of 55-57,70 



NIP (see Nucleus initialization program) 
Nondispatchability flags, TCB 207 
Nonreusable module 

purging of module after its use is 
complete 191 
Normal termination 199-203 
Nucleus initialization program (NIP) 

entry point name of 741 

module name for 717 

synopsis of 751 



Open/Close routine (see Communications 

task) 
Opening the dump data set 234-236 
Operator communications queues 

purging of 230 
OPSW (see RB old PSW, SVC old PSW, External 

interruptions) 
Options routine (see Communications task) 
ORDERCDQ routine 191-192 
Overlay supervisor 

description of 89-90 

entry point names of 742 

flowchart of 462 

module names for 722,727 

synopsis of 754 

types of processing 90 



Parameter list element (ENQ/DEQ routines) 

format of 303 
PARRLSE routine 231 
Partially loaded modules 

release of 231 
Partition queue element 
construction of 109 
definition of 5 
format of 327 
Partitioned data set directory entry (see 

Data set directory entry) 
PC FLIH (see Program-Check First-Level 

Interruption Handler) 
PDS directory entry (see Data set directory 

entry) 
PFK routines (see Communications task) 
PICA (see Program interruption control 

area) 
PIE (see Program interruption element) 
Post routine 



description of 47-49 

entry point names of 792 

flowchart of 425-426 

module name for 717,726 

synopsis of 754 
Posting an event control block 

general (see Post routine) 

posting the I/O supervisor ECB 97 

posting the parent task's ECB 202-203 

posting the program fetch ECB 97 
PQE (see Partition queue element) 
PRB (see Program request block) 
Preserve routine 

description of 178-179 

entry point names of 735 

flowchart of 591 

module names for 723 
Processor routines (see Communications 

task) 
Program Check First-Level Interruption 

Handler 20-21 
Program Fetch buffer table 97 

format of 317 
Program Fetch Channel- End Appendage routine 

description of 101 

entry point name of 742 

flowchart of 459-461 

module name for 716 

synopsis of 755 
Program Fetch PCI Appendage routine 

description of 100,101 

entry point name of 742 

flowchart of 459-461 

module name for 716 

synopsis of 755 
Program Fetch routine 

description of 95-97 

entry point names of 742 

flowchart of 459-461 

module name for 722 

synopsis of 755 
Program Fetch work area 

description of 97 

format of 316 

initialization of 97 
Program interruption control area (PICA) 

construction of 43 

format of 300 
Program interruption element (PIE) 

construction of 43 

format of 300 

normal release of 200 

purging of 230 
Program interruptions 20-21 
Program request block (PRB) 

abnormal release of 248 

construction of 80 

definition of 4 

format of 296 

normal release of 191 
Purge Timer routine 

entry point of 742 

flowchart of 646 

function of 230 

module name for 717 

synopsis of 755 
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QCB (see Queue control block) 
QCB queues 

abnormal removal of elements from 2t4 

construction of 53 

illustration of 50-52 

normal removal of element from 59 

origin of 718 
QEL (see Queue element (QEL) for 

serializing the use of a resource) 
QEL queues 

abnormal removal of elements from 24U 

construction of 53 

illustration of 50-52 

normal removal of element from 59 
Qname 50 
Queue control block (QCB) 

abnormal release of 24" 

construction of 53 

formats of 304 

normal release of 59 
Queue element (QEL) for serializing the use 
of a resource 

abnormal release of 244 

construction of 53 

format of 305 

normal release of 59 



RB (see Request block) 
RB old PSW 

saving of 13 
RBREMOVE subroutine 245 
Recovery Management (see Machine-Check 

Handler) 
Recovery options for machine checks and 

channel errors 25-26 
Recursion, ABEND 

flags 224 

invalid 223 

valid 223-224 
Refreshing a transient area block (see 

Transient Area Refresh routine) 
Region of main storage 

allocation of 107-111 

freeing of 129-130 
Relative Priority routine 71 
Release Loaded Programs routine 

description of 201 

entry point name of 743 

flowchart of 647 

module name for 717 

synopsis of 755 
Release Main Storage routine 

description of 201 

entry point name of 74 3 

flowchart of 647 

module name for 718 

synopsis of 755 
Releasing main storage 

at end of task 201 

during abnormal termination 249 

in response to a FREEMAIN macro 
instruction 135 
Relocation list dictionary record 96,97 

format of 319 
RELPRIOR routine (see Relative Priority 

routine) 
Reply Purge routine (see WTOR Purge 



routine) 
Reply queue element 

abnormal release of 230 

definition of 123 

format of 329 
Repmain routines 

description of 182 

entry point names of 743 

flowcharts of 598-602 

module names for 726 
Request block 

definition of types 4 

dummy (see Dummy request block for the 
system error task) 

fields and formats of (see Interruption 
request block, format of; Program 
request block, format of; Supervisor 
request block, format of; System 
interruption request block, format of) 

normal release of 188-189 

purging of 247-248 
Request queue element (RQE) 

abnormal return to free list 230 

definition of 63 

formats of 308 

normal return to free list 65-66 

queuing of 64 
Requesting one or more resources via an ENQ 

macro instruction 49-50 
Requests for user exit routines 

purging of 230-231 
Resident display control module 

description of 160-161 

format of 337 
RESERVE macro instruction 

as used in Dequeue routine 62 

as used in Enqueue routine 58 
"Reset must complete" function 

description of 60-61 
Resource queues for ENQ/DEQ requests 53 
Responsibility count (LLCOONT) 88,248-249 

format of 310 

(see also Load list element) 
Restart Exit routine 

description of 186 

entry point name of 744 

flowchart of 612 

module name for 724 
Restart Housekeeping routines 

description of 182 

entry point neimes of 743 

flowchart of 597 

module name of 725 
Resume I/O routine 

description of 180 

entry point name of 735 

flowchart of 595 

module name of 724 
RET parameter 

effect of during DEQ processing 58 

effect of during ENQ processing 52-54 
RIQE (see Rollout I/O queue element) 
RLD buffer 97 
RLD record 

format of 319 
Rname 50 

Roll Mode routine (see Communications task) 
ROLL parameter 33 
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Rollout 1/0 Queue Element (RIQE) 

construction of 123 

format of 328 

normal release of 133 
Rollout/Rollin feature 7 
Rollout/Rollin module 

description of 117-124 

entry point name of 744 

flowcharts of 468-475 

module name for 718 

scheduling of 113-117 

synopsis of 755 
RQE (see Request queue element) 
RQE queue (AEQA) 

placing element on 64 

removing element from 65-66 

(also see Request queue element, 
abnormal return to free list) 



Sample dump 

foirmat of 368 
SCANTREE subroutine 205 
Scatter extent list 

format of 313 
Scatter/translation record 

format of 315 
SCB (see STAE control block) 
Secondary communications vector table 

format of 333 
Second CPU Recovery Management System 
Interface routine 

description of 23-24 

entry point name of 744 

module name for 731 
SEGLD macro instruction 

linkage to the Overlay Supervisor 
for 90 
SEGLD Processor routine 

description of 92 

entry point name of 744 

flowchart of 462 

module name for 731 

synopsis of 756 
Segment table 89 

format of 321 
SEGTAB (see Segment table) 
SEGWT macro instruction 

linkage to the Overlay Supervisor 
for 90 
SER routines (see SERO routine and SERl 

routine) 
Serializing the use of a resource 49-50 
SETSDBS subroutine 205,207 
SERO routine 

description of 27 

entry point names of 744 

flowchart of 407 

module names for 717,722,731 

synopsis of 756 
SERl routine 

description of 27-29 

entry point name of 744 

flowcharts of 408-410 

module name for 717 

synopsis of 756 
"Set must complete" function 55 
Set Status routine 



description of 70-71 

entry point name of 744 

flowchart of 451-452 

module name for 728 

synopsis of 756 
Severe error condition 

recognizing a 228 
Shared Direct Access Device feature 

description of 7 

Dequeue routine with 
description of 62 
flowchart of 427-428 

Enqueue routine with 

description of 58-59 
flowchart of 427-428 
3H0LDTAP routine 

description of 72 

synopsis of 756 
SHPC (see Six-hour pseudo clock) 
SIRB (see System interruption request 

block) 
Six-hour pseudo clock 137-138 
SMF (see System Management Facility) 
SPEOT routine (see Release Main Storage 

routine) 
SPIE routine 

description of 43-44 

entry point name of 744 

flowchart of 422 

module name for 727 

synopsis of 756 
SPQE (see Subpool queue element) 
SQA (see System queue area) 
STAE 

macro instruction 43,253 

Service routine 

description of 253-254 
entry point name of 744 
flowchart of 437 
module name for 725 
synopsis of 756 
STAE control block (SCB) 

format of 301 
Stage 1 Exit Effector 

description of 64 

entry point name of 745 

flowchart of 431 

module name for 727 

synopsis of 756 
Stage 2 Exit Effector 

description of 64 

entry point name of 745 

flowchart of 432 

module name for 719 

synopsis of 756 
Stage 3 Exit Effector 

description of 65-66 

entry point names of 745 

flowchart of 433-434 

module name for 716,719 

synopsis of 756 
Status Display Interface routines (see 

Communications task) 
STATUS macro instruction 

analysis of parameters 70-71 
Steal Core Subroutine 243 
STIMER routine 

description of 140 
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entry point name of 7U5 

flowchart of 477,482 

module name for 727 

synopsis of 756 
Storage Reconfiguration 

ABENDO routine with 
description of 226 
flowchart of 655-657 

ABENDl routine with 
description of 228 
flowchart of 658-662 

ABEND 7 routine with 
description of 233 
flowchart with 669-670 

ABEND 20 routine with 

description of 250-251 
flowchart of 694 

CDEXIT routine with (flowchart) 623 

general description of 29 
Storage utilization Block (SUB) 

definition of 160 

format of 366 
Subpool 

indicating shared ownership of 34 

relationship with types of GETMAIN 
requests 110 
Subpool End-of-Task routine (see Release 

Main Storage routine) 
Subpool queue element (SFQE) 

abnormal release of 249 

construction of 111 

format of 324 

normal release of at end of task 201 
Subtask 

attaching of 30-31 

detaching of 40-42 

queue 34-35 
Supervisor request block 

abnormal release of 244-245,248 

construction of 13-14 

definition of 4 

format of 291-292 

normal release of 193 
SVe DUMP 

description of 221-222 

entry point names of 733 

flowcharts of 761-763 

module names for 724 
SVC First-Level Interruption Handler 

description of 12 

entry point name of 745 

flowchart of 396 

module name for 718 

synopsis of 756-757 
SVC FLIH (see SVC First^Level Interruption 

Handler) 
SVC interruption handling 

for nonresident (transient) SVC 
routine 14-15 

for type-1 SVC routine 12 

for resident SVC routine requiring an 
SVRB 13 
SVC Old PSW 12 
SVC purge parameter list 123 

format of 330 
SVC Purge routine 

entry point name of 745 

function of 230 



module name for 727 
synopsis of 757 
SVC Second-Level Interruption Handler 
description of 13-15 
entry point names of 745 
flowchart of 397 
module name for 718 
synopsis of 757 
SVC SLIH (see SVC Second- Level 

Interruption Handler) 
SVC table 12 

format of 278 
SVRB (see Supervisor request block) 
SYNCH processing 

description of 75 
entry point name 736 
flowchart of 453-455 
module name for 727 
SYSABEND data set (see Dump data set) 
SYSIN/SYSOUT Data Set Processors 
description of 184-185 
entry point names of 743 
flowchart of 607 
module names for 724 
SYSIN/SYSOUT Non-Direct Access Data Set 
Processor 

description of 184 
entry point name of 744 
module name for 724 
System error task 65 
System error TCB 65 

entry point name of 745 
module name for 716 
System error transient area (see I/O 

supervisor transient area) 
System interruption request block 4,65 
format of 295 
initialization of 66 
System log 172-174 
System Management Facility 
Attach routine with 
description of 33 
flowchart of 411-415 
detailed description of 8,270-272 
Dispatcher routine with 
description of 195 
flowchart of 624-642 
EXCP Counting routine 

description of 271-272 
flowchart of 711-712 
External FLIH routine with 

multiprocessing flowchart of 405 
uniprocessing flowchart of 404 
FREEMAIN routine with 
description of 130 
flowchart of 463-465 
FMSMFCRE routine 

description of 130 
flowchart of 463-465 
GETMAIN routine with 
description of 112 
flowchart of 463-465 
GMSMFCRE routine 

description of 112 
flowchart of 463-465 
Input/Output FLIH routine with 
description of 24 
flowchart of 406 



Index 775 



Output Limit Expiration routine 

description of 143,272 

flowchart of 713 
Timer SLIH routine with 143 

flowchart of 479-480 
Timing Control Table 272 
wait routine with 

description of 46 

flowchart of 423-424 
Wait Time collection routine 

description of 271 

flowchart of 714 
System queue area 107,129,135 
SYSUDUMP data set (see Dump data set) 
SYSl.DUMP data set 

with Damage Assessment Routine 251 
SYSl.LINKLIB data set 

data control block (DCB) 

entry point name for 737 

module name for 731 
data extent block (DEB) 

entry point name for 737 

module name for 731 
SYSl.LOGREC data set 26 
SYSl.SVCLIB data set 

data control block (DCB) 

entry point name of 737 

module name for 731 
data extent block (DEB) 

entry point name of 737 

module name for 731 



TAB (see Transient area block) 

TABLDL (see Transient area fetch routine) 

TACT (see Transient area control table) 

TAHABEND subroutine 244-245 

TAHEXIT subroutine (see Transient Area 

Exit routine) 
TAHFETCH (see Transient Area Fetch 

routine) 
TARESTRT (see SVC Second-Level 

Interruption Handler) 
Task asynchronous exit routine 

scheduling of 43 

specifying of 253 
Task control block 

abnormal release of 249-250 

construction of 30 

definition of 3 

flags 283-289 

format of 283 

normal release of 202-203 

queuing of 34-35 

System (pseudo task) 195 
Task Removal routine 

description of 71 

entry point name of 745 

module name for 732 

synopsis of 757 
Task Switching routine 

description of 68-70 

entry point name of 745 

flowchart of 435-436 

module name for 719 

synopsis of 757 
Task timing 

description of 196-197 



flowchart of 625-626 
TAXEXIT (see Transient Area Exit routine) 
TAXRETRY (see Transient Area XCTL routine) 
TCAM ABDDMP modules 

description of 221 

entry point names of 733 

flowchart of 653 

module names for 723 
TCAM Data Set Processor 

description of 183 

entry point name of 743 

flowchart of 613-614 

module name for 723 
TCB (see Task control block) 
TCT (see Timing Control Table) 
TESTDSP routine (see Task Removal routine) 
TESTRAN interpreter 

entry point names of 746 

module names for 722,727 

use by the common subroutines of 
Contents Supervision 78 

use by the Models 91 and 195 22,259 

Program Interruption Handler 22 

use by the Overlay Supervisor 462 
Time of expiration 139 
Time routine 

description of 137-138 

entry point names of 746 

flowchart of 476,481 

module name for 727 

synopsis of 757 
Time Sharing Option (TSO) 

Dequeue routine with 427-428 

description of 7 

End-of-Task routine with 200,202 

Fetch and BLDL processing with 19 

issuing ATTACH with 35 

issuing CHAP with 37 
flowchart of 416-419 

local system queue area 128,135 

POST with TJID 47 

Stage 3 Exit Effector with 66 

subpool allocation 108 

timer interruption with 141 

time sharing link pack area 
extension 75,77 

TSEVENT macro instruction 19,47,141,148 

TSO Dispatcher 196 

user exit routine with 192 
Time-slice control element 

pointers of 37 

creation of 4 

format of 336 
Time-slicing feature 

Attach routine with 
description of 34 
flowchart of 411-415 

Chap routine with 

description of 36 
flowchart of 417-419 

description of 6-7 

Dispatcher routine with 
description of 195-196 
flowchart of 628-630,634-642 

EOT routine with 

description of 202 
Timer Interpreter routine (see 
Communications task) 
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Timer interruption handling 140-141 
Timer queue 

positioning of elements on 139-140 
purging elements from 230 
Timer queue element 

abnormal release of 230 

construction of 140 

definition of 139 

format of 331 

normal removal from timer queue 141-142 
Timer Second-Level Interruption Handler 

description of 141-142 

entry point names of 746 

flowchart of 479-480,484 

module name for 718,719 

synopsis of 757 
Timer SLIH (see Timer Second-Level 

Interruption Handler) 
Timing 

job step 197-198 

task 197 
Timing Control Table 272 
TOX (see Time of expiration) 
TQE (see Timer queue element) 
Trace routine 

entry point names of 746 

function of 8, 273 

module name for 732 

synopsis of 757 
Trace table 8,273 

format of 297-298 
Tracing facilities 2,273 
Transient Area Availability Check routine 

description of 16 

entry point name of 746 

flowchart of 399 

module name for 732 

synopsis of 757 
Transient area block 16 
Transient area control table (TACT) 16 

format of 299 
Transient Area Exit routine 

description of 189 

entry point names of 746 

flowchart of 6 21 

module name for 718,732 

synopsis of 757-758 
Transient Area Fetch routine 

description of 19 

entry point names of 746 

flowchart of 400 

module name for 732 

synopsis of 758 
Transient area fetch task 18 
Transient area fetch TCBs 

entry point names of 746 

function of 18 

module name for 718 
Transient area handler 15-20 
Transient area I/O blocks (lOBs) and 
associated transient area blocks 

entry point names of 746 

module name for 732 
Transient Area Refresh routine 

description of 192 

entry point name of 746 

flowchart of 622 

module name for 718 



synopsis of 758 
Transient area user count 

address of 333 

definition of 84 
Transient Area XCTL routine 

description of 81 

entry point neunes of 747 

flowchart of 453-455 

module name for 718,732 

synopsis of 758 
Transient display control module 

description of 160-161 

format of 340 
TSCE (see Time-slice control element) 
TTIMER routine 

description of 143-144 

entry point name of 747 

flowchart of 478,483 

module name for 727 

synopsis of 758 
Twenty-four hour pseudo clock (T4PC) 138 
Type-1 Exit routine 

description of 187 

entry point names of 747 

flowchart of 617 

module name for 719 

synopsis of 758 
Type-1 SVC message 

description of 232 

freeing of WTP buffer 232 

purging of message list 
elements 231, 232 
Type-1 SVC switch (lEATYPEl) 

entry point name of 747 

function of during ABTERM 
processing 211 

module name for 718 
T4PC (see Twenty- four hour pseudo clock) 



Unit Control Module 

Base 348 

description 160 

Entry Individual Device Map 351 

MCS Prefix 349 

Message Text and Event Indication 
List 353 
UCM Extension Prefix 349 
Use/responsibility count 88 
User Exit routine 

scheduling of 62-64 



Validity Check routine 

description of 70 

entry point name of 747 

module name for 719 

synopsis of 758 
Vary Storage Offline routine 

description of 129-130 

synopsis of 758 
Vary queue element (VQE) 

format of 347 
VQE (see Vary queue element) 



Wait routine 

description of 44 
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entry point name of 747 

flowchart of 423-424 

module name for 726 

synopsis of 758 
Where-to-Go routine 

cleanup in 221 

function of 214 
WQE (see Write queue element) 
Write queue element 

Major WQE 356-357 

MCS (single-line WTO) 354 

Minor WQE 359-360 
Write- to- Log routine 

entry point name of 747 

module name for 722 

synopsis of 758 
Write-to-Operator routine 

entry point name of 747 

module name for 724 

synopsis of 758 
Write-to-Programmer routine 6,149 
WRITELOG Available Log Data set routine 

entry point name of 747 

module name for 721 

synopsis of 758 
WRITELOG command 172 
WRITELOG Dispatch routine 

entry point name of 747 

module name for 721 

synopsis of 758 
WRITELOG Get Region routine 

entry point name of 747 

module name for 721 

synopsis of 758 
WRITELOG Log Initialization routine 

entry point name of 747 

module name for 721 

synopsis of 758 
WRITELOG Log Writer routine 

entry point name of 747 

module name for 722 

synopsis of 758 



WRITELOG Master Wait routine 

entry point name of 747 

module name for 722 

synopsis of 758 
WRITELOG Open Device routine 

entry point name of 747 

module name for 721 

synopsis of 758 
WTL routine 172 

(see also Write-to- Log routine) 
WTO routine (see Write-to-Operator 

routine) 
WTO/R Macro Expansion 361 
WTOR macro instruction 172 
WTOR Purge routine 

entry point name of 747 

function as used by ABEND routine 230 

function as used by EOT routine 200 

module name for 721 

synopsis of 759 



XCTL processing 

description of 80-81 
entry point name of 736 
flowchart of 453-455 
module name for 727 



2K Storage Reconfiguration (see Storage 
Reconfiguration) 
1288 Support 

fetching error routine 66 
flowchart 433-434 
2250 System Operator's Console Support 

routines (see Communications task) 
2260 System Operator's Console Support 
routines (see Communications task) 
2860/2870/2880 Channel-Check support 
description of 2 
Transient Area Fetch I/O error 26 
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